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16.  Abstract 

This  chapter  provides  an  overview  of  Artificial  Intelligence  (AI)  technology,  one  of  the  more  complex  applications  of  digital 
systems.  This  chapter  examines  Al-based  technology,  focusing  on  three  fields:  neural  networks,  fuzzy  logic,  and  Expert 
Systems.  This  chapter  provides  the  reader  with  the  background  and  a  basic  understanding  of  the  fundamentals  of  these  fields. 
Another  section  examines  aspects  of  the  AI  development  environment,  including  languages,  tools,  and  Al-based  hardware 
components. 

Some  of  the  proposed  aviation-related  applications  for  both  civil  and  military  aircraft,  including  pilot  assistants  and  diagnostic 
aids,  are  surveyed.  Additionally,  certification  issues,  including  regulations,  guidelines,  and  verification  and  validation 
techniques  are  examined.  Human  factors  issues  relating  to  the  use  of  this  technology  are  identified  and  reviewed.  In  addition, 
this  chapter  identifies  safety  issues  and  concerns  over  the  use  of  this  technology  in  airborne  systems. 
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EXECUTIVE  SUMMARY 


This  tutorial  was  initiated  by  the  Federal  Aviation  Administration  Technical 
Center's  Directorate  for  Aircraft  Safety,  Flight  Safety  Research  Branch.  The 
purpose  of  the  tutorial  is  to  provide  an  overview  of  Artificial  Intelligence  (AI) 
technology,  highlighting  selected  fields.  This  tutorial  is  based  on  the 
technical  report  DOT/FAA/CT-94/41  with  the  same  title. 

One  of  the  more  complex  applications  of  digital  systems  is  that  of  AI .  This 
report  examines  Al-based  technology,  the  development  environment,  and  proposed 
aviation— related  applications  of  this  technology.  In  addition,  the  report 
identifies  safety  issues  and  concerns  over  the  use  of  this  technology  in  airborne 
systems.  There  are  seven  sections  of  the  report: 

■  Section  1  -  Introduction 

■  Section  2  -  Artificial  Intelligence  Overview 

■  Section  3  -  Artificial  Intelligence  and  Expert  System  Development 

•  Section  4  -  Artificial  Intelligence  and  Expert  System  Applications 

■  Section  5  -  Certification  Considerations  for  Artificial  Intelligence 

■  Section  6  -  Human  Factors  and  Artificial  Intelligence 

■  Section  7  -  Conclusion 

While  Al-based  technology  may  never  be  able  to  replace  genuine  intelligence,  it 
can  provide  users  with  many  benefits.  Developing  human— centered  automation  and 
designing  advanced  technology  that  will  capitalize  on  the  relative  strengths  of 
humans  and  machines  are  key  to  the  success  and  usefulness  of  AI .  For  example, 
Expert  Systems  (ESs)  can  consistently  provide  expert  advice  in  a  timely  manner. 
ESs  are  not  influenced  by  factors  which  impair  human  decision  making,  such  as 
stress  or  emotions . 

Neural  Network  systems  are  helpful  for  applications  such  as  pattern  recognition. 
Recognizing  pre-failure  signatures  in  airborne  machinery  is  an  excellent 
application  for  this  particular  field  of  AI .  Fuzzy  logic  systems  are  useful  for 
applications  that  normally  require  human  intuition,  are  difficult  to  control  with 
conventional  techniques,  or  are  difficult  to  model. 

One  of  the  primary  activities  that  requires  addressing  by  developers  and 
certification  specialists  concerns  Verification  and  Validation  (V&V)  methods  for 
Al-based  systems.  Numerous  V&V  techniques  that  have  been  successfully  applied 
to  ESs  are  identified  in  this  tutorial.  Identifying  a  set  of  tests  that  can  be 
demonstrated  to  satisfy  safety  requirements  will  be  a  challenge. 

AI  technology  is  not  efficient  at  solving  all  types  of  problems.  For  a  number 
of  applications,  it  can,  however,  assist  in  managing  problem  complexity.  Al- 
based  systems  for  commercial  aircraft  are  being  researched  and  tested. 
Ultimately,  such  systems  can  offer  economic  advantages  and  contribute  to  flight 
safety. 
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1. 


INTRODUCTION 


1.1  Defining  Artificial  Intelligence 

Because  of  ongoing  debate  over  what  comprises  Artificial  Intelligence  (AI) 
technology  and  what  the  research  goals  are,  it  is  difficult  to  provide  an 
unequivocal  definition  of  AI .  Should  some  fields  of  AI  technology,  such  as 
Expert  Systems  (ESs)  or  fuzzy  logic,  be  considered  simply  another  software 
application?  Should  a  system  without  learning  capability  be  considered  an  AI- 
based  system,  as  some  believe?  Others  contend  that  due  to  fundamental 
differences  between  computers  and  people,  the  ultimate  goal  of  the  autonomous 
"thinking  machine"  will  never  be  realized.  Human  qualities,  such  as  intuition, 
can  not  be  reproduced  in  the  confines  of  silicon  and  software  (Dreyfus  and 
Dreyfus  1986). 

Debate  over  these  issues  will  continue.  Numerous  definitions  of  what  comprises 
AI  technology  exist.  However,  for  the  purpose  of  this  report,  AI  is  defined  as 
the  subfield  of  computer  science  that  attempts  to  use  computers  to  emulate  the 
way  humans  think  and  reason  when  solving  problems.  This  agrees  with  Wickens 
(1992) : 

The  study  of  AI  is  devoted  to  developing  computer  programs  that  will 
mimic  the  product  of  intelligent  human  problem  solving,  perception, 
and  thought. 

Defined  in  this  manner,  AI  includes  systems  that  are  capable  of  "learning,"  as 
well  as  those  that  have  static  rules  and  databases.  The  part  of  the  definition 
that  is  stressed,  and  that  most  agree  with,  is  the  mimicking,  or  emulating,  of 
human  techniques. 

In  this  report,  particular  emphasis  is  placed  on  three  fields  of  AI  technology: 
ESs,  fuzzy  logic,  and  Neural  Networks  (NNs) .  Aviation-  and  avionics-related 
applications,  or  proposed  applications,  have  been  numerous  for  these  disciplines, 
but  especially  for  the  ES .  Therefore,  sections  4,  on  AI  applications,  and  5,  on 
certification  issues,  focus  on  these  fields  of  AI  technology. 

1.2  Artificial  Intelligence  and  Aviation  Applications 

AI  technology  has  existed  for  a  number  of  years.  During  the  early  years,  the 
promises  made  concerning  this  technology  did  not  match  the  products  delivered. 
With  this  in  mind,  Bouchard  (1991)  said: 

The  user  community  has  been  stung  with  high  development  costs  and 
false  expectations,  although  that  is  changing  with  respect  to  expert 
systems . 
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Some  of  the  early  applications  of  AI— based  technology  have  included  image  and 
speech  recognition  systems,  natural  language  systems,  and  handwriting  analysis. 
While  research  in  these  fields  continues,  Al-based  technology  is  being  used  in 
a  number  of  other  applications.  AI— based  systems  are  now  being  used  for  control 
and  monitoring  systems,  financial  analysis,  medical  prognosis,  manufacturing, 
training,  sorting  through  large  amounts  of  data  in  databases,  and  scheduling. 
A  great  amount  of  research  is  being  performed  and  sponsored  by  the  National 
Aeronautics  and  Space  Administration  (NASA)  for  space  applications  and  for 
potential  flightdeck  applications  for  both  the  commercial  and  military 
communities.  Among  the  Department  of  Defense  (DOD)  community,  this  technology 
is  referred  to  as  "Machine  Intelligence."  Al-based  systems  are  also  being  used 
by  the  Nuclear  Power  Industry  (Naser  1991).  Some  of  the  benefits  of  such  systems 
include  consistency  of  reasoning  in  stressful  situations,  reduction  in  time  to 
perform  certain  tasks,  and  prevention  of  equipment  failures  using  predictive 
diagnostics . 


Al-based  products  that  save  the  user  time  and  money  and  outperform  conventional 
software— based  systems  are  currently  being  manufactured.  According  to  Curran 
(1992),  it  is  likely  that  AI  and  ES  technology  will  be  used  in  the  near  future 
in  at  least  two  avionic  areas.  For  the  aviation  community,  the  possible  benefits 
of  using  Al-based  systems  would  include  the  following: 


Optimizing  the  use  of  airspace 
Reducing  the  cost  of  flying 

Meeting  Air  Traffic  Control  (ATC)  requirements 
Aiding  the  decision  making  process  of  the  flight  crew 
Aiding  maintenance  activity 
Assisting  data  management 


AI— based  pilot  aid  systems  are  being  designed  by  both  military  and  commercial 
manufacturers.  In  Germany,  the  Cockpit  Assistant  System  (CASSY) ,  an  Al-based 
pilot  aid  system,  is  undergoing  flight  testing,  with  the  expectation  that  it  will 
be  operational  as  early  as  1997  (Nordwall  1992).  This  system  may  use  Al-based 
technologies,  such  as  NNs ,  ESs,  and  fuzzy  logic  (Prevot,  Onken,  and  Dudek  1991). 
Certification  authorities  in  Europe  and  the  United  States  should  be  cognizant  and 
concerned  over  such  activity.  Above  all,  they  should  be  prepared  for  the 
presentation  of  such  an  Al-based  system  for  certification  by  an  avionics  or 
airframe  manufacturer. 


AI  is  a  broad  discipline  and  this  report  is  limited  in  scope  and  depth  of 
coverage.  For  further  information,  the  reader  is  urged  to  make  use  of  the 
bibliography  located  after  section  7 . 
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2.  ARTIFICIAL  INTELLIGENCE  OVERVIEW 


As  stated  in  the  introduction,  AI  refers  to  the  subfield  of  computer  science  that 
studies  the  process  of  programming  machines  to  perform  in  a  manner  resembling 
human  behavior.  It  is  the  computer-based  solution  to  complex  problems  using  the 
application  of  processes  that  are  analogous  to  the  human  reasoning  process 
(Rolston  1988) . 

Many  disciplines  contribute  ideas  to  the  field  of  AI .  Basic  ideas  in  fields  such 
as  mathematics,  psychology,  linguistics,  philosophy,  computer  science,  and 
engineering  find  frequent  application  in  AI .  Intelligence  requires  many 
strengths  and  many  of  the  problems  faced  in  established  disciplines  intersect  the 
natural  concerns  of  Al-related  problems. 

Two  of  the  objectives  of  AI  are  to  make  computers  more  useful  and  to  understand 
the  principles  that  make  intelligence  possible  in  living  beings.  As  the  world 
grows  more  complex,  Al-based  computers  can  assist  with  many  tasks.  Resources 
such  as  energy,  food,  and  brain  power  must  be  used  as  wisely  as  possible.  High 
quality  help  from  computers  in  ordinary  computing,  as  well  as  computing  that 
exhibits  intelligence,  can  assist  in  this  area. 

The  ultimate  goal  of  AI  research  is  to  build  a  "person."  This  person  will  have 
various  modules  that  will  be  integrated  to  produce  the  final  system.  These 
modules  involve  a  number  of  different  applications  relevant  to  AI  research.  The 
input  to  the  system  includes  vision  and  language  interfaces  with  the  external 
domain.  The  output  of  the  system  entails  robotics,  speech,  and  screen 
interaction  with  the  external  domain.  The  internal  systems  include  deduction, 
search,  planning,  explanation,  and  learning  (Charniak  and  McDermott  1985). 

Intelligence  requires  more  than  the  ability  to  reason;  it  also  requires  a  great 
deal  of  knowledge  about  the  world.  The  knowledge  about  the  world  needs  to  be 
encoded  in  a  way  that  the  computer  system  will  be  able  to  interpret.  There  are 
some  properties  inherent  in  knowledge  that  cause  difficulty  for  Al-related 
purposes.  Knowledge  is  difficult  to  characterize  accurately;  it  is  constantly 
changing;  it  is  virtually  unbounded;  and  it  generally  needs  to  be  organized 
according  to  the  way  it  will  be  used  (Rich  and  Knight  1991)  . 

Robotics  is  a  significant  subarea  of  AI .  There  are  many  possible  uses  for 
robots.  Tasks  such  as  welding,  general  house  cleaning,  construction,  and  making 
deliveries  would  be  appropriate  for  a  robot.  Robotics  is  a  complex  area 
involving  aspects  other  than  AI ,  such  as  mechanical  and  electrical  design. 
Successful  implementation  of  a  fully  operational,  independent  robot  has  not  been 
achieved.  Tasks  that  are  performed  almost  unconsciously  by  humans  require  many 
of  the  same  abilities  used  in  solving  more  intellectually  demanding  problems. 
Complex  robot  control  problems  require  planning  at  high  levels  of  abstraction, 
ignoring  details,  and  then  planning  at  lower  and  lower  levels  where  details 
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become  important.  Research  into  the  area  of  robotics  has  helped  to  develop  many- 
other  AI  areas . 

Interfacing  with  the  user  requires  capabilities  such  as  voice  and  visual 
interface.  Further  investigation  into  these  areas  is  required  for  them  to  be 
useful  to  an  AI  system.  An  area  of  AI  that  requires  more  research  and 
development  is  natural  language  comprehension.  This  is  the  ability  of  an  AI 
system  to  interpret  written  or  spoken  words.  Human  communication  employs  complex 
and  little  understood  processes  almost  effortlessly.  The  primary  use  of  language 
is  to  transmit  a  piece  of  mental  structure  from  one  brain  to  another  under 
circumstances  in  which  each  brain  possesses  large,  highly  similar  surrounding 
mental  structures  that  serve  as  a  common  context.  A  computer  system  capable  of 
understanding  a  message  in  natural  language  would  require  both  the  contextual 
knowledge  and  the  processes  for  making  the  inferences  assumed  by  the  message 
generator  (Nilsson  1980) . 

Common  sense  reasoning  involves  reasoning  about  physical  objects  and  their 
relationships  to  each  other,  as  well  as  reasoning  about  actions  and  their 
consequences.  For  example,  an  object  can  only  be  in  one  place  at  a  time,  and  if 
an  object  is  dropped  it  will  fall  to  the  floor  and  may  break.  This  reasoning  is 
difficult  to  capture  because  it  is  taken  for  granted.  People  do  not  need  to 
think  about  actions  related  to  common  sense  reasoning;  they  are  virtually 
instinctive.  At  this  point  in  AI  development,  the  domains  that  require  only 
specialized  expertise  without  the  assistance  of  common  sense  knowledge  are  the 
AI  systems  that  are  flourishing  as  useful  systems. 

Another  area  of  AI  research  is  intelligent  retrieval  from  databases.  Database 
systems  are  computer  systems  that  store  a  large  body  of  facts  about  some  subject 
in  such  a  way  that  the  data  can  be  used  to  answer  questions  about  that  subject. 
Many  techniques  have  been  developed  to  enable  the  efficient  representation, 
storage,  and  retrieval  of  large  numbers  of  facts.  These  techniques  become 
related  to  AI  when  the  task  requires  retrieving  answers  that  entail  deductive 
reasoning  from  the  facts  in  the  database.  The  designer  of  an  intelligent 
database  retrieval  system  is  faced  with  several  problems ,  including  understanding 
queries  that  are  stated  in  natural  language,  deducing  answers  from  stored  facts, 
and  acquiring  and  utilizing  common  knowledge. 


Expert  consulting  systems  are  systems  that  provide  users  with  expert  conclusions 
about  specialized  subject  areas.  These  systems  include  medical  diagnostic 
systems,  which,  given  the  symptoms  of  the  patient,  may  suggest  tests  to  perform 
and,  possibly,  speculate  what  the  disease  may  be  (Charniak  and  McDermott  1985). 
The  key  problem  in  developing  expert  consulting  systems  is  how  to  represent  and 
use  the  knowledge  that  experts  possess  and  use.  This  knowledge  is  often 
imprecise  or  uncertain. 

The  task  of  a  computer  generating  a  computer  program  is  related  to  both  theorem 
proving  and  robotics.  The  system  takes  in  a  description  of  what  the  program  is 
supposed  to  do  and  then  writes  the  code.  Program  verification  and  debugging  are 
a  few  of  the  capabilities  that  such  a  system  must  achieve. 

Specifying  optimal  schedules  and  combinations  is  another  class  of  problems  that 
can  be  solved  using  AI  techniques.  The  effort  is  in  making  the  time— versus- 
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problem— size  curve  grow  as  slowly  as  possible.  Several  methods  have  been 
developed  for  delaying  and  moderating  the  inevitable  combinatorial  explosion. 
Knowledge  about  the  problem  domain  is  the  key  to  more  efficient  solution  methods. 

Research  is  being  done  in  the  area  of  a  computer's  ability  to  perceive 
surroundings.  It  would  be  useful  for  computers  to  be  capable  of  understanding 
their  surroundings  by  hearing  and  seeing  them.  Understanding  surroundings 
requires  a  large  database  of  knowledge  about  the  things  being  perceived.  The 
ultimate  goal  is  to  represent  the  scene  by  a  natural  language  description.  The 
process  of  hypothesis  formation  requires  a  large  amount  of  knowledge  about  the 
expected  scenes.  For  example,  when  a  robot  enters  a  room,  there  will  be  some 
information  in  the  AI  system  about  what  normally  can  be  expected  to  be  found  in 
a  room,  such  as  windows,  doors,  and  furniture. 

A  task  that  may  be  appropriate  for  an  AI  system  is  proving  or  disproving  a 
theorem.  This  requires  intuitive  skills,  such  as  guessing  which  theorems  should 
be  proved  first  to  prove  the  main  theorem  and  the  ability  to  make  deductions  from 
hypotheses.  There  are  many  informal  tasks  that  can  be  formalized  as  theorem 
proving  problems.  Therefore,  this  is  an  important  area  in  the  study  of  AI 
methods  (Nilsson  1980) . 

There  are  AI  programs  that  can  perform  a  variety  of  tasks,  such  as  solving 
mathematical  problems,  predicting  the  presence  of  mineral  deposits,  verifying  the 
designs  of  electronic  components,  and  using  television  cameras  to  see  the  world 
and  identify  what  is  there.  AI  programs  are  also  capable  of  playing  backgammon, 
controlling  manufacturing  processes,  diagnosing  computer  faults,  designing 
computers,  underwriting  insurance,  playing  chess,  and  much  more  (Charniak  and 
McDermott  1985) . 

Three  subfields  of  AI  are  examined  in  detail  in  the  following  sections.  They  are 
ESs,  fuzzy  logic,  and  NNs .  ESs  are  programmed  to  use  the  knowledge  of  experts 
applied  to  specific  task  areas.  ESs  can  achieve  high  levels  of  system 
performance  in  limited  domains.  Fuzzy  logic  is  used  to  model  systems  where 
information  may  be  imprecise  or  incomplete.  Fuzzy  logic  is  useful  for  systems 
that  normally  require  human  intuition,  are  difficult  to  control  with  conventional 
techniques,  or  are  difficult  to  model.  NNs  are  a  simplified  model  of  the  brain's 
structure.  They  are  used  to  solve  problems  that  require  input  to  output  data 
mapping. 

2.1  History 

Beginning  in  the  1960s,  there  was  much  interest  in  developing  intelligent 
systems.  Many  promises  were  made  regarding  the  future  capabilities  of  computers. 
However,  by  the  early  1970s,  most  of  the  promises  that  were  made  had  not  been 
met.  AI  research  lost  most  of  its  funding  and  was  regarded  as  an  eccentric 
branch  of  computer  science.  People  became  skeptical  of  AI  because  of  unrealistic 
claims  and  expectations.  Interest  and  activity  in  the  area  of  AI  research  grew 
again,  beginning  in  the  late  1970s  and  peaking  in  the  mid-1980s.  Fuzzy  logic  was 
developed  in  1965  as  a  method  of  capturing  human  expertise  and  incorporating  it 
into  ESs.  There  is  still  a  significant  amount  of  research  being  done  in  the 
field  today. 
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Initially,  the  aim  of  AI  was  to  develop  universal  models  for  general  problem 
solving.  However,  soon  it  became  apparent  that  this  would  rule  out  too  many 
specific  types  of  problems  (Adeli  1990) .  Compared  to  other  branches  of 
engineering  and  computer  science,  AI  is  a  very  young  field.  Scientists  and 
engineers  are  still  struggling  to  find  its  rightful  place  in  the  scientific 
world.  Although  AI  may  not  live  up  to  early  expectations,  it  can  still  benefit 
many  applications. 

2.2  Expert  Systems 

An  ES  is  a  computer-based  system  designed  to  emulate  the  problem  solving  behavior 
of  a  human  who  is  an  expert  in  a  narrow  domain.  ESs  are  based  on  AI  techniques 
that  use  knowledge  about  a  particular  domain  and  reasoning  techniques  to  perform 
activities  normally  done  by  human  experts.  They  are  created  by  first  capturing 
the  domain  expert's  knowledge  and  then  translating  and  storing  this  knowledge  in 
a  computer  readable  format,  discussed  in  more  detail  below.  ESs  emulate  the 
reasoning  process  of  a  human  expert,  sometimes  reasoning  from  imprecise  and 
uncertain  information.  They  solve  real-world,  complex  problems,  using  a  computer 
model  of  expert  human  reasoning.  These  systems  provide  a  way  to  make  the 
knowledge  of  experts  available  to  many. 

Research  in  ESs  began  in  the  middle  1960s.  There  is  an  extensive  body  of 
knowledge  covering  a  number  of  different  approaches  to  ESs.  Research  and 
development  for  these  systems  is  continuing  at  a  rapid  pace.  There  are  many  ESs, 
either  in  use  or  under  development,  for  providing  assistance  in  diverse 
applications  such  as: 

•  Performance  monitoring  and  diagnosis  of  telecommunication  systems 

•  Soil  analysis 

■  Decision  aiding  for  military  maneuvers 

■  Data  quality  assurance  in  the  Consumer  Price  Index 

■  Computer  hardware  configuration  for  large  computer  systems 

A  number  of  other  applications  related  to  avionics  are  examined  in  section  4. 

Research  in  the  area  of  languages  to  support  symbolic  reasoning  has  been  done  in 
conjunction  with  AI  and  ES  research.  List  Processor  (LISP),  which  is  currently 
the  most  widely  used  AI  language,  was  developed  in  1958.  Another  widely  used  AI 
language  is  PROLOG  (PROgramming  in  LOGic) .  Additional  languages  used  in  AI 
system  development  can  be  found  in  section  3. 

Although  there  are  other  methods  of  encoding  knowledge,  ESs  generally  encode 
knowledge  through  a  set  of  rules  that  are  in  the  form  of  IF  THEN  statements.  ESs 
compute  a  sequence  of  strings  representing  the  steps  in  the  solution  to  a 
problem.  To  simulate  the  human  reasoning  process,  ESs  apply  specific  knowledge 
and  inferences.  They  are  able  to  deal  with  a  wide  range  of  problems,  as  would 
a  human  expert. 

High  performance  of  ESs  can  only  be  achieved  on  powerful  computing  platforms 
because  a  great  number  of  rules  are  needed  in  the  knowledge  base. 
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2.2.1  Expert  System  Architecture 

The  main  sections  of  an  ES  are  a  knowledge  base,  a  database,  and  an  inference 
mechanism.  An  interface,  whether  human  or  with  another  system,  must  also  be 
included.  Figure  2.2-1  shows  the  ES  architecture.  The  database  contains  the 
current  state  of  the  ES  as  it  works  toward  a  solution.  The  knowledge  base 
contains  domain  knowledge  which  is  applied  to  the  problem  at  hand.  Information 
in  the  knowledge  base  may  be  in  the  form  of  statements,  such  as  the  (attribute) 
of  (object)  is  (value),  or  it  may  be  in  the  form  of  an  IF  THEN  statement  (rule). 
Attributes  are  terms  such  as  age,  distance,  or  temperature,  and  they  may  not  be 
known  precisely  (Togai  and  Watanabe  1992).  The  inference  mechanism,  or  inference 
engine,  controls  the  use  of  the  knowledge  base  and  database  in  solving  the 
problem. 


User/Other  System 


FIGURE  2.2-1.  EXPERT  SYSTEM  ARCHITECTURE 


2. 2. 1.1  Knowledge  Base 

The  knowledge  base  contains  codified  knowledge  about  a  specific  domain.  It  is 
a  collection  of  facts  and  heuristics.  The  power  of  an  ES  depends  more  on  the 
quality  of  its  knowledge  base  than  on  the  nature  of  its  inference  engine.  Large 
knowledge  bases  can  be  difficult  to  develop  and  maintain. 

2 . 2 . 1 . 2  Database 

The  database  contains  an  organized  collection  of  specific  data  concerned  with  the 
problem  to  be  solved.  It  represents  what  the  computer  believes  to  be  either  a 
partial  or  full  solution  to  the  problem.  The  inference  engine  acts  as  a 
gatekeeper  between  the  database  and  the  program  using  it.  The  inference  engine 
is  responsible  for  adding  and  deleting  beliefs  and  performing  certain  classes  of 
inference,  such  as  adding  facts  or  handling  requests  for  information  (Charniak 
and  McDermott  1985)  . 

2. 2. 1.3  Inference  Engine 

The  function  of  the  inference  engine  is  to  use  knowledge  in  the  knowledge  base , 
along  with  acquired  knowledge  about  the  specific  problem,  to  form  an  expert 
solution.  To  achieve  defined  goals,  the  inference  engine  controls  and  executes 
reasoning  using  the  knowledge  contained  in  the  database  and  the  knowledge  base. 


20-7 


The  system's  general  problem  solving  knowledge  is  contained  in  the  inference 
engine . 

The  inference  engine  must  be  able  to  determine  when  it  is  appropriate  to  ask  the 
user  for  information  and  when  it  should  consult  the  knowledge  base  and  database. 
The  inference  engine  needs  to  be  flexible  to  deal  with  varying  situations.  It 
also  may  be  required  to  handle  imprecise  and  ambiguous  information. 

A  well  designed  inference  engine  will  be  able  to  make  use  of  many  different 
patterns  of  evidence  and  use  these  to  narrow  the  scope  of  possible  conclusions . 
Various  search  techniques  are  used  by  the  inference  engine  and  applied  to  the 
knowledge  base  and  database  to  reach  a  solution.  Search  techniques  are  examined 
later  in  this  report. 

2.2.2  Expert  System  Implementation 

ESs  that  are  most  accepted  by  users  and  are  most  successful  have  a  number  of 
common  qualities  (Hall  and  Kandel  1992) : 

■  Problem  domain  has  limited  focus. 

•  User  interaction  is  minimal. 

■  Problem  domains  are  well  defined  and  manageable  -  the  more  limited  and 
focused  the  domain,  the  less  knowledge  is  needed  and  the  less  information 
that  must  be  verified  and  tracked. 

■  Experts  are  available  for  consultation. 

•  Solution  verification  is  straightforward  and  noncontroversial . 

■  The  systems  are  not  consultation  systems,  i.e. ,  systems  that  claim  to  give 
indisputable  expert  advice. 

ESs  that  have  not  gained  wide  acceptance  by  users  typically  do  not  have  a  good 
user  interface,  are  slow  in  responding,  and  often  ask  too  many  questions  of  the 
user.  Many  unsuccessful  systems  are  consultation  or  diagnostic  ESs  that  do  not 
explain  their  problem  solving  processes  to  the  user's  satisfaction. 

Rols ton  (1988)  categorizes  current  ESs  into  three  general  classes: 

■  Assistant  -  Performs  a  technically  limited  subset  of  an  expert's  task; 
however,  generally  it  is  an  economically  worthwhile  system. 

■  Colleague  -  Performs  a  significant  subset  of  an  expert's  task. 

•  Expert  -  Performs  at  an  expert's  level  within  a  given  domain.  This  type 
of  system  requires  a  large  knowledge  base  and  powerful  development  tools . 

Most  systems  fall  into  the  assistant  or  colleague  class.  It  Is  difficult  to 
design  a  system  that  is  capable  of  replacing  an  expert  in  a  complex  domain. 
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2.2.3  Explanation  of  Reasoning 

The  ability  of  an  ES  to  justify  to  the  user  exactly  how  it  came  to  a  particular 
conclusion  is  important.  The  user  will  gain  trust  in  the  system  more  quickly  if 
there  is  an  understanding  of  how  a  conclusion  was  reached.  Also,  errors, 
inconsistencies,  and  omissions  are  more  easily  detected  in  the  debugging  process 
if  the  path  of  reasoning  can  be  traced. 

2.2.4  Knowledge  Representation 

Knowledge  is  the  fundamental  part  of  an  ES  and  is  where  the  system  achieves  its 
power  to  solve  problems  (Rolston  1988).  The  effective  representation  of  domain 
knowledge  is  considered  the  key  to  the  success  of  AI  programs.  When  choosing  a 
form  of  knowledge  representation,  an  important  consideration  for  the  designer 
should  be  the  ease  with  which  knowledge  can  be  changed  and  updated.  Flexibility 
is  essential  to  handle  input  from  human  experts  who  often  may  change  their  minds. 
It  is  necessary  to  model  a  knowledge  domain  accurately. 

Knowledge  representation  language  is  the  method  used  to  represent  facts. 
Knowledge  is  defined  in  terms  that  can  be  manipulated  by  programs.  Two  common 
representation  languages  are  natural  language  (English  language  sentences)  and 
symbolic  (representations  of  objects  at  the  knowledge  level  defined  in  terms  of 
symbols).  Basic  criteria  for  a  knowledge  representation  language  are  as  follows 
(Fikes  and  Kehler  1985) : 

■  Expressive  power  -  Experts  must  be  able  to  communicate  their  knowledge 
effectively  to  the  system. 

■  Under standability  -  Experts  must  be  able  to  understand  what  the  system 
knows . 

■  Accessibility  -  The  system  must  be  able  to  use  the  information  it  has  been 
given. 

The  knowledge  representation  must  facilitate  inferencing,  which  converts  the 
explicit  set  of  beliefs  about  a  problem  domain  to  a  larger  effective  set  of 
beliefs.  Three  main  ways  of  representing  knowledge  in  an  ES  are  rules,  semantic 
networks,  and  frames. 

Rules  are  a  formal  method  of  representing  strategies,  recommendations,  and 
directives.  Years  of  problem  solving  experience  in  a  particular  domain  result 
in  empirical  associations  that  are  suitable  for  representation  by  use  of  rules. 
An  inference  engine  sorts  through  the  rules  and  available  data  to  reach  a 
conclusion. 

Semantic  networks  originally  were  developed  to  be  psychological  human  memory 
models.  Their  use  is  now  commonplace  in  the  AI  field.  The  network  represents 
knowledge  by  using  nodes  and  arcs.  Nodes  can  represent  objects,  concepts,  or 
events,  while  arcs  are  used  to  represent  relationships  or  hierarchies  between  the 
nodes . 
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Frames  are  similar  to  semantic  networks  in  that  both  nodes  and  arcs  are  used  for 
representing  knowledge.  For  frames,  however,  the  nodes  can  take  on  a  collection 
of  attributes  with  their  associated  values.  Each  attribute  can  have  attached 
procedures  that  execute  when  a  value  is  changed. 

2. 2.4.1  Rule-Based  Systems 

Rules  are  a  subset  of  predicate  calculus  with  additional  components  to  signify 
the  way  information  in  the  rules  should  be  used  for  reasoning  (Fikes  and  Kehler 
1985).  Predicate  calculus  represents  knowledge  about  real-world  facts  as 
statements . 

Most  current  AI  technology  is  rule— based.  Rule— based  systems  constitute  the  best 
presently  available  means  for  codifying  the  problem  solving  methods  of  human 
experts.  They  are  the  most  commercially  successful  AI  products. 

Rules  are  the  most  popular  and  effective  representational  form  for  behavioral 
knowledge  in  knowledge  systems.  Rules  are  fairly  simple  to  work  with  and  are 
relatively  independent  of  each  other.  This  independence  allows  incremental 
construction  of  AI  systems.  Rules  also  are  able  to  represent  different  types  of 
knowledge.  Experts  find  it  easy  to  state  their  knowledge  in  the  form  of  rules. 
Rules  lend  themselves  to  expressing  the  heuristic  knowledge  that  comes  from 
experience  (Friedland  1985) . 

Experts  generally  express  most  of  their  problem  solving  methods  in  terms  of 
situation— action  rules.  Rule— based  systems  can  incorporate  rules  that  imitate 
the  way  experts  reason.  Rules  must  allow  one  to  encode  an  expert's  knowledge  as 
thoroughly  and  efficiently  as  possible,  and  the  rule— based  system  must  be  able 
to  convey  its  knowledge  and  reasoning  schemes  to  people  of  varying  skill  levels. 
Other  types  of  systems  lack  the  reasoning  schemes  used  by  experts  and,  therefore, 
cannot  solve  practical  problems  efficiently. 

All  rule-based  systems  have  several  properties  in  common  (Hayes-Roth  1985): 

■  They  use  IF  THEN  rules  to  Incorporate  human  knowledge. 

•  They  use  larger  knowledge  bases  to  perform  at  a  higher  skill  level. 

■  They  have  the  ability  to  solve  a  wide  range  of  problems  by  combining  rules 

appropriately . 

■  They  determine  the  best  sequence  of  rules  to  pursue. 

■  They  can  explain  their  reasoning  by  retracing  their  steps. 

The  rule  base  contains  an  expert's  knowledge  that  is  used  to  solve  a  problem. 
A  rule-based  controller  models  the  behavior  of  the  human  expert,  as  opposed  to 
modeling  the  problem  solving  methodology.  This  is  a  flexible  approach  to 
codifying  knowledge  and  is  well-suited  for  representing  the  knowledge  used  to 
control  a  system. 
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The  usefulness  of  a  rule— based  system  is  dependent  upon  the  fidelity  of  knowledge 
and  problem  representation.  Problem  solving  using  a  rule— based  system  goes 
through  many  cycles  of  identifying  the  rules  that  have  bearing  on  a  particular 
problem  and  then  applying  those  rules  to  solve  the  problem  or  achieve  the  end 
goal. 

Rules  can  express  the  following  (Hayes-Roth  1985): 

•  Deductive  knowledge  -  Logical  relationships,  inference,  verification,  and 
evaluation. 

■  Goal— oriented  knowledge  -  Used  in  seeking  problem  solutions. 

■  Causal  relationships  -  Used  to  determine  possible  causes  for  specified 
events . 

Control  rules  represent  the  expert's  problem  solving  strategy.  These  rules  are 
a  way  to  achieve  control  over  the  system  while  maintaining  clarity.  There  are 
two  types  of  control  rules:  those  that  represent  knowledge  and  those  that 
represent  the  problem  solving  strategy.  The  rules  that  represent  the  problem 
solving  strategy  are  a  special  type  of  ES  knowledge  called  meta-knowledge. 
Basically,  meta-knowledge  is  knowledge  about  the  system  knowledge.  However, 
meta-knowledge  often  can  worsen  system  transparency  by  complicating  testing  and 
making  maintenance  difficult.  System  transparency  means  that  the  system's 
knowledge  is  dependant  neither  on  its  location  in  the  system  nor  on  any  of  the 
other  knowledge  found  in  the  system.  Further  research  is  needed  so  that  ways  to 
better  represent  meta-knowledge  can  be  identified.  For  applications  that  are 
more  than  trivial,  transparency  and  simplicity  of  the  code  seem  to  diminish 
(Coats  1991) .  Separating  declarative  and  procedural  knowledge  makes  the  system 
easier  to  code,  debug,  and  maintain. 

If  rules  are  transparent,  their  meaning  is  completely  independent  of  their 
location  in  the  rule  base.  However,  this  means  the  order  in  which  the  rules  are 
processed  is  difficult  to  determine  by  examining  the  rules  themselves. 
Conventional  programming  has  low  transparency  but  high  behavioral  visibility. 
Conventional  programming  controls  the  way  programs  process  information. 
Controlling  the  way  programs  process  information  is  detrimental  to  rule— based 
programming  since  it  creates  knowledge  bases  that  are  difficult  to  read  and 
maintain.  ESs  are  programmed  to  tell  the  system  what  to  know,  while  conventional 
programming  instructs  the  system  what  to  do. 

Sometimes  rules  may  include  procedural  content.  They  represent  knowledge  of 
procedures  and  methods  to  process  data.  Generally,  there  is  little  information 
in  the  knowledge  base  about  when  rules  should  fire  (execute).  In  theory,  using 
rules  to  represent  procedural  knowledge  can  be  risky  because  it  can  cause 
knowledge  to  become  intertwined.  When  this  occurs,  it  becomes  difficult  to 
follow  the  steps  taken  to  solve  the  problem.  The  rule  base  and  the  inference 
engine  which  processes  the  rule  base  should  be  separate.  Global  control 
strategies  should  be  context  free.  The  selected  control  strategies  may  be 
applied  regardless  of  the  situation. 


20-11 


When  procedural  content  is  included  in  the  rules ,  they  become  less  independent 
of  each  other  and  their  position  begins  to  play  a  crucial  role  in  producing 
correct  results.  Proceduralizing  among  the  rules  as  opposed  to  within  the  rules 
also  should  be  avoided.  Rules  should  not  be  grouped  together  to  imply  procedures 
as  a  group.  Rules  should  reflect  knowledge,  not  procedures,  and  avoid  implicit 
or  hidden  meanings.  A  particular  problem  may  be  more  suited  to  traditional 
programming  techniques  when  procedural  content  within  the  rules  cannot  be 
avoided. 

When  debugging  a  conventional  program,  normally  the  challenge  for  the  programmer 
is  in  determining  which  statements  are  out  of  order.  The  sequence  of  events  is 
followed  easily.  In  an  ES ,  the  challenge  is  to  determine  how  the  inference 
engine  is  processing  the  rules,  ensuring  that  the  rules  are  correct,  and 
adjusting  the  inference  engine's  method  of  processing  the  rules. 

Conventional  computer  programming  requires  programmers  to  think  procedurally , 
while  rule— based  programming  requires  programmers  to  think  more  analytically. 
Rule  programming  is  similar  to  conventional  programming  because  it  requires 
mental  modeling  of  state  changes,  syntactic  and  semantic  checking  of  rule 
conditions,  and  heuristic  methods  for  validating  and  verifying  a  proposed  system 
(Hayes— Roth  1985) . 

As  with  conventional  computer  programming,  structure  is  critical.  A  well- 
structured  rule  base  is  easier  to  test  and  maintain  and  better  represents 
knowledge.  In  classic  rule-based  ESs,  an  inference  engine  processes  a  knowledge 
base  composed  of  rules .  The  separation  of  the  knowledge  base  and  the  processor 
of  the  knowledge  makes  the  rule-based  ES  easier  to  develop,  test,  and  maintain. 
Because  of  this,  rules  can  be  manipulated  without  affecting  processing  or  other 
rules . 

Automating  expertise  in  specialized  tasks  generally  requires  a  few  hundred  to  a 
few  thousand  heuristic  rules  (Hayes-Roth  1985) . 

A  rule-based  system  consists  of  three  elements: 

■  A  working  memory  (database)  -  Contains  data  structures  that  represent  the 
current  solution  state  of  the  system  or  intermediate  results.  Contents 
change  until  the  final  solution  is  found. 

■  A  set  of  rules  (knowledge  base)  -  Contains  IF  THEN  statements  from  rules 
and  facts.  This  is  a  permanent,  static  structure. 

■  An  inference  engine  -  Contains  hardware  and  software  that  matches  the 
conditions  in  the  rules  to  the  entries  in  working  memory  and  fires  the 
rules  if  there  is  a  match. 

Two  useful  characteristic  features  of  rule-based  systems  are  incremental 
development,  which  allows  knowledge  to  be  refined  and  added,  and  explanation  of 
reasoning,  which  aids  in  understanding  computer  systems. 

Guidelines  for  a  well-structured  knowledge  base  are  given  below  (Pederson  1991) : 
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■  Keep  conclusions  simple  -  Rules  should  only  update  one  attribute  at  a 
time;  the  results  are  clear  and  easy  to  follow;  and  it  is  easy  to  tell 
which  rule  is  responsible  for  which  action. 

■  Keep  rules  free  of  procedural  content. 

■  Minimize  the  use  of  ELSE  constructs. 

A  poorly  structured  rule— based  ES  would  be  analogous  to  excessive  use  of  GOTO 
statements  in  conventional  programming.  It  is  difficult  to  follow  the  path  that 
the  program  is  taking,  and,  therefore,  more  difficult  to  debug.  Rules  with 
multiple  conclusions  or  the  use  of  ELSE  statements  result  in  a  process  that  is 
confusing  to  follow. 

To  be  successful,  a  rule-based  ES  should  have  the  following  characteristics 
(Weiss  and  Kulikowski  1984) : 

■  The  conclusions  must  be  generated  by  the  system  from  a  finite  set  of 
discrete  and  prespecif iable  elements. 

■  The  evidence  about  the  problem  must  be  obtained  reliably  by  the  user  of 
the  system  or  the  system  itself. 

•  The  initial  assumptions  must  limit  the  problem  to  a  highly  specialized 
area. 

■  A  knowledge  base  must  be  available  to  link  evidence  about  the  problem  to 
conclusions. 

•  A  reasoning  control  strategy  must  be  designed  to  guide  the  reasoning  of 
the  system  and  make  its  output  correspond  to  that  of  a  human  expert. 

The  types  of  knowledge  that  can  be  included  in  rule-based  systems  follow  (Hayes- 
Roth  1985): 

■  Inferences  that  follow  from  observations 

■  Generalizations  of  data 

•  Conditions  for  achieving  a  goal 

■  Best  places  to  find  relevant  information 

■  Best  strategies  for  eliminating  uncertainty  and  minimizing  risks 

■  Probable  causes  of  symptoms 

■  Likely  outcomes  of  hypothetical  situations 

Future  goals  for  rule-based  systems  include  the  following: 

■  Increasing  the  size  of  the  rule  base  to  10,000  or  more  rules 

■  Increasing  the  processing  speed 

■  Using  more  inference  techniques 

■  Improving  reasoning  with  uncertainty 

■  Simplifying  the  process  of  creating  and  extending  knowledge  bases 

■  Sharing  knowledge  bases 
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■  Improving  architectures 

■  Generating  more  efficient  ES  development  tools 

Rule-based  systems  have  the  ability  to  capture,  represent,  store,  distribute, 
reason  with,  and  apply  human  knowledge.  They  are  a  practical  solution  to 
building  automated  experts  and  are  especially  applicable  in  tasks  that  require 
consistency  and  practical  experience.  Although  AI  developers  have  generated 
other  approaches,  the  rule-based  method  is  the  only  one  that  consistently 
produces  accurate  results .  Rule— based  systems  offer  advantages  that  cannot  be 
found  in  traditional  programming  techniques  (Hayes-Roth  1985): 

■  Modularity 

•  Knowledge  bases  that  store  rules  and  facts  and  make  decisions 

■  Explanations  of  results 

■  Easily  understood  beliefs  and  problem  solving  techniques 

■  Inference  chains  (the  path  of  reasoning  and  searching  that  the  inference 
engine  follows  to  achieve  a  goal)  that  are  efficient 

2.2.4. 1.1  Rule  Architecture 

Rules  basically  are  independent  pieces  of  knowledge.  As  the  rule  base  gets 
larger,  rule  components  (antecedent,  conclusion)  must  be  flexible  and  independent 
enough  so  that  extension  and  maintenance  of  the  knowledge  base  will  not  adversely 
affect  them  (Hayes-Roth  1985).  The  rules  are  in  the  form  of  IF  THEN  statements 
and  may  contain  the  knowledge  of  one  or  more  experts.  The  inference  engine 
manages  the  rule  base  by  using  search  expressions  or  algorithms. 

The  left  side  of  the  rule  is  the  situation  recognition  part,  known  as  the 
antecedent  or  premise.  The  right  side  is  the  action  part,  referred  to  as  the 
conclusion  or  consequent.  The  antecedent  expresses  some  condition  in  the  state 
of  the  database  and  describes  if  and  when  it  is  satisfied.  Usually  it  consists 
of  a  sequence  of  clauses  connected  by  AND  or  OR,  which  serve  as  minimum  and 
maximum  operators.  The  action  part  specifies  what  changes  are  to  be  made  to  the 
database  when  a  rule  is  satisfied.  The  inference  engine  monitors  the  facts  in 
the  database  and  when  an  antecedent  is  satisfied,  it  executes  the  corresponding 
action. 

The  current  facts,  along  with  the  inference  engine,  make  up  the  computing 
environment .  Together  they  serve  to  interpret  the  current  state,  understand  the 
meaning  of  the  rules,  and  apply  the  rules  appropriately. 

When  the  consequent  defines  an  action,  scheduling  the  action  for  execution 
satisfies  the  antecedent.  When  the  consequent  defines  a  conclusion,  inferring 
the  conclusion  will  satisfy  the  antecedent. 
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There  are  several  functions  that  the  rules  perform  (Hayes-Roth  1985) : 

■  Simplify  auditing  and  explanation  by  having  the  ability  to  trace  every 
result  to  its  antecedent  and  intermediate  inferences . 

■  Simulate  reasoning  by  expressing  logical  relationships. 

•  Simulate  human  understanding. 

■  Simulate  human  decision  making  by  using  conditional  rules  to  express 
heuristics . 

The  rules  must  cover  all  possible  combinations.  If  no  antecedents  are  satisfied, 
then  no  action  will  be  taken. 

2.2.4. 1.1.1  Reasoning  with  Inexact  Concepts 

Certainty  Factors  (CFs)  are  values  that  represent  the  level  of  belief  associated 
with  a  fact  or  a  rule.  They  are  a  means  of  providing  a  judgement  about  the 
certainty  of  a  conclusion,  which  is  determined  by  combining  degrees  of  belief  and 
disbelief.  The  CF  is  based  on  the  level  of  certainty  known  about  conditions  in 
the  premise.  Every  time  a  new  rule  is  considered,  a  new  CF  is  calculated.  The 
use  of  CFs  is  a  technique  for  supplementing  existing  reasoning  processes  with 
information  regarding  uncertainty.  Normally,  an  interval  between  0  and  1  is  used 
to  represent  the  CF,  with  1  being  absolute  certainty. 

2.2.4. 2  Semantic  Networks 

A  semantic  or  associative  network  is  a  way  of  representing  knowledge.  Nodes 
represent  objects,  concepts,  or  situations  in  the  domain.  Arcs  (links)  represent 
relationships  between  the  nodes.  A  network  is  a  representation  of  the  relations 
between  elements  in  a  domain  using  interweaving  and  crisscrossing  arcs  (Rolston 
1988).  A  semantic  network  is  a  graphical  representation  of  a  network.  Figure 
2.2-2  shows  the  semantic  network  architecture.  Arcs  can  also  have  weights,  which 
indicate  the  strength  of  the  relationship  between  the  nodes . 

Arc  labels  indicate  the  basis  of  the  relationship  between  the  two  arcs.  An  arc 
can  be  viewed  as  something  that  is  asserted  to  be  true  about  one  element  relative 
to  another  (Rolston  1988).  For  example,  "DC-10"  is  linked  to  "aircraft." 

Semantic  networks  are  easy  to  read.  They  are  based  on  an  object-oriented 
illustration,  meaning  the  representation  is  based  on  objects  that  are  treated  as 
independent  pieces  of  knowledge  in  the  computer.  Semantic  networks  are 
represented  in  a  computer  by  using  memory  addresses  to  depict  the  arcs  that  go 
from  one  node  to  another.  This  facilitates  access  to  all  parts  of  the  semantic 
network. 

2. 2. 4. 3  Frames 

The  organization  of  frames  is  similar  to  that  of  semantic  networks.  Frames 
consist  of  a  set  of  slots  that  contain  data,  procedures,  or  pointers  to  other 
frames.  The  pointers  can  create  nested  frames.  When  slot  relations  warrant  some 
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FIGURE  2.2-2.  SEMANTIC  NETWORK  STRUCTURE 


action,  the  procedures  will  define  the  type  of  action  to  be  taken  (Hall  and 
Kandel  1992).  Frames  provide  structured  representation  of  an  object  or  class  of 
objects.  Table  2.2-1  illustrates  the  frame  architecture.  Frames  are  well-suited 
for  applications  in  which  complex  descriptions  are  needed  to  depict  the  domain 
accurately.  They  provide  the  knowledge  base  builder  with  a  means  of  describing 
the  types  of  specialized  objects  that  the  system  must  model. 


TABLE  2.2-1.  FRAME  STRUCTURE 


Frame  Label 

Facette  1 

Facette  2 

Facette  3 

slot! 

valuen 

value12 

value13 

slot2 

value2i 

value22 

value23 

s  lotjj 

valuenl 

valuen2 

valuen3 

Frames  provide  the  ability  to  interpret  new  situations  on  the  basis  of  knowledge 
gained  from  similar  situations.  Often,  in  the  beginning  of  frame  development, 
a  best  fit  frame  must  be  chosen  for  the  current  situation  because  there  may  not 
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be  an  exact  frame  that  fits  at  that  time  (Rolston  1988)  .  As  development 
continues,  frames  may  be  added  and/or  changed. 

Frames  are  appropriate  for  representing  prototypical  knowledge  and  the  properties 
of  objects  to  be  modeled.  Frames  identify  specific  pieces  of  knowledge  that 
belong  together  in  a  group.  Frames  are  made  up  of  pieces  of  knowledge  that  are 
typical  characteristics  of  the  ideas  associated  with  that  particular  frame  label. 
The  pieces  of  knowledge  in  the  frame  are  called  facettes  and  they  take  on  values 
that  uniquely  identify  the  characteristics  of  a  specific  object. 

For  example,  a  particular  frame  may  be  labeled  Aircraft  Accident.  The  facettes 
that  may  be  contained  in  that  frame  include  components  normally  associated  with 
any  aircraft  accident: 

■  Cause 

•  Number  of  passengers 

■  Number  of  crew  members 

•  Number  of  injuries 

■  Location 

■  Date 

■  Time 

For  an  aircraft  accident,  these  facettes  are  filled  with  values  that  can  identify 
a  specific  accident.  When  the  values  are  entered  into  the  facette,  the  result 
is  a  particular  instance  of  the  general  concept  Aircraft  Accidents  represented 
as  a  frame  (Adeli  1990) . 

Frames  are  an  excellent  way  for  a  knowledge  system  to  organize  and  direct  its 
reasoning  activities.  As  with  semantic  networks,  frames  are  an  object-oriented 
form  of  representation.  The  use  of  frames,  along  with  rules,  may  be  a  promising 
area  for  improvements  in  knowledge  representation.  When  representing  knowledge, 
rules  and  frames  integrated  in  a  single  unified  representation  scheme  work  best. 

2.2.5  Updating  the  Knowledge  Base 

Machine  learning  is  a  process  by  which  a  system  generates  and  updates  its 
knowledge  base.  The  system  learns  from  past  experience.  This  is  the  ultimate 
goal  for  updating  a  knowledge  base.  This  area,  however,  has  not  been  perfected 
and  requires  more  research. 

Knowledge  also  can  be  updated  manually.  This  process  is  performed  by  a  knowledge 
engineer  who  interprets  and  encodes  knowledge  from  a  human  expert.  Another  form 
of  updating  knowledge  is  for  the  expert  to  enter  knowledge  directly  into  the 
system  with  the  assistance  of  a  tool  designed  to  perform  the  knowledge  engineer's 
tasks.  The  knowledge  engineer  is  eliminated. 

2.2.6  Chaining 

Chaining  refers  to  the  path  of  rules  that  the  inference  engine  fires  to  achieve 
a  solution.  The  inference  engine  can  process  information  in  one  of  two  ways: 
forward  or  backward  chaining.  Some  ESs,  such  as  blackboard  systems,  use  a 
combination  of  the  two  methods . 
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2.2.6 .1  Forward  Chaining 

Forward  chaining  uses  bottom  up  or  event  driven  reasoning.  A  rule  is  triggered 
when  changes  in  working  memory  data  produce  a  situation  that  matches  its 
antecedent  component.  This  method  begins  with  some  initial  data  and  moves  down 
the  inference  chain  until  it  reaches  a  solution  to  the  problem.  Working  memory 
is  used  to  store  the  new  facts.  Working  memory  also  stores  initial  observations, 
findings,  and  conclusions. 

2 . 2 . 6 . 2  Backward  Chaining 

Backward  chaining  is  the  process  of  working  backward  from  a  known  conclusion  to 
find  a  path  of  reasoning  to  justify  the  conclusion.  The  goal  is  assumed  to  be 
true  and  the  inference  engine  searches  for  evidence  to  support  that  conclusion. 
The  rule-based  system  begins  with  a  goal  and  successively  examines  any  rules  with 
matching  consequent  components .  The  unmet  conditions  of  the  antecedent  are  taken 
from  each  applicable  rule  and  then  defined  as  new  goals  (Hayes-Roth  1985).  In 
backward  chaining,  working  memory  is  used  to  note  unresolved  subgoals.  This  is 
also  known  as  goal  directed,  or  top  down,  reasoning. 

2.2.7  Knowledge  Acquisition 

Knowledge  acquisition  is  a  lengthy  process  in  which  the  knowledge  engineer  must 
meet  with  a  known  expert  who  is  willing  to  provide  information.  It  is  a  tedious 
process  and  creates  a  bottleneck  in  ES  development.  It  is  one  of  the  most 
difficult  phases  of  ES  building.  The  knowledge  acquisition  process  is  not  well 
understood  or  well  defined  (Rolston  1988) . 

Knowledge  can  be  represented  as  procedural  or  declarative.  Most  declarative 
schemes  are  knowledge  represented  as  static  facts,  along  with  a  limited  amount 
of  information  that  describes  how  the  information  should  be  used. 

An  ES  shell  is  an  ES  with  an  empty  knowledge  base.  ES  shells  require  knowledge 
engineering  that  extracts  a  collection  of  highly  detailed  facts  from  a  human 
expert  and  programs  them  into  a  database.  This  process  requires  repeated  testing 
of  the  program  to  verify  and  account  for  all  possible  situations. 

Both  procedural  and  declarative  knowledge  are  needed  for  every  ES .  However,  they 
should  be  kept  as  separate  as  possible.  Generally,  procedural  knowledge  is  found 
in  phe  inference  engine  and  declarative  knowledge  is  found  in  the  rule  base . 

The  inference  engine  utilizes  meta-knowledge.  Meta-knowledge  includes 
information  on  how  to  utilize  available  knowledge,  in  what  order  the  knowledge 
should  be  used,  where  the  knowledge  can  be  obtained,  and  the  point  at  which 
processing  is  complete. 


Knowledge  engineering  can  be  an  expensive,  time  consuming,  and  difficult  task  for 
the  following  reasons  (Adeli  1990) : 

■  Vocabulary  -  The  knowledge  engineer  must  comprehend  the  basic  vocabulary 

of  the  domain. 
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■  Completeness  -  The  knowledge  engineer  must  understand  the  domain 
sufficiently  to  identify  pieces  missing  from  the  knowledge  base. 

■  Integration  -  New  information  must  be  added  to  the  knowledge  base  in  a  way 
that  will  not  adversely  affect  existing  knowledge. 

■  Analysis  -  The  knowledge  engineer  must  have  the  ability  to  evaluate  the 
expert's  methods  for  arriving  at  conclusions. 

■  Transparency  -  The  knowledge  engineer  must  incorporate  the  expert's 
problem  solving  behavior  into  the  knowledge  base. 

Knowledge  engineers  need  to  have  a  working  knowledge  of  the  domain  that  is  being 
modeled.  They  need  to  become  proficient  in  the  field  to  be  able  to  comprehend 
the  expert's  information  and  to  determine  how  to  handle  situations.  For  example, 
the  knowledge  engineer  must  determine  how  to  handle  contradictions  and 
inconsistencies  between  experts.  The  knowledge  engineer  may  need  to  resolve 
conflicting,  redundant,  subsuming,  or  missing  blocks  of  knowledge. 

Several  tools  have  been  developed  to  assist  knowledge  engineers  with  prototype 
development.  Some  tools  may  replace  the  knowledge  engineer  with  an  automated 
acquisition  system.  Any  system  intended  to  replace  the  knowledge  engineer  must 
be  able  to  perform  all  knowledge  engineering  tasks. 

2.2.8  Applications 

Applications  suitable  for  ESs  are  presented  below: 

■  Applications  where  a  proven  expert  is  available. 

■  Systems  that  entail  robot  activities. 

•  Limited  domains  with  well  defined  expertise. 

■  Systems  that  do  not  require  extensive  user  interaction. 

■  Problems  that  do  not  have  a  large  amount  of  uncertain  information.  (An  ES 
will  no  longer  be  appropriate  when  a  specific  level  of  uncertainty  is 
reached. ) 

The  use  of  an  ES  may  be  justified  when  experts  are  rare  or  soon  will  be 
unavailable,  identical  expertise  is  needed  in  many  locations,  or  the  expertise 
is  needed  in  a  hostile  environment. 

If  the  problem  to  be  solved  can  be  described  by  direct  definitions  and 
algorithms,  it  may  be  solved  better  by  traditional  software  methods.  In 
addition,  if  the  problem  is  extremely  difficult  to  define  or  requires  intense 
judgement,  it  may  be  too  complex  for  an  ES  and  will  need  to  be  solved  by 
traditional  methods  (Rolston  1988). 
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A  number  of  characteristics  are  common  to  ESs  in  use  today: 

•  There  are  proven  experts  available. 

•  The  task  requires  a  well  defined  domain  without  changing  rules . 

■  The  problem  requires  more  cognition  than  physical  attributes. 

■  The  problem  takes  an  expert  a  few  minutes  to  a  few  hours  to  solve. 

■  The  experts  teach  their  skills  and  are  able  to  explain  their  reasoning. 

■  Solving  the  problem  will  produce  considerable  benefits . 

•  The  problem  solution  requires  no  common  sense. 

■  There  is  low  risk  if  a  bad  decision  is  made. 

An  ES  attempts  to  find  an  acceptable,  but  not  necessarily  the  best  solution,  in 
a  reasonable  amount  of  time.  It  deals  with  a  specific  problem  domain,  as  opposed 
to  attempting  to  mimic  human  behavior  in  all  domains  (Rolston  1988)  . 

2.2.9  Heuristic  Reasoning 

An  heuristic  is  any  rule  of  thumb  or  strategy  that  is  used  to  limit  the  time 
required  to  search  for  solutions  in  large  problem  areas  (Coats  1991).  Heuristics 
is  the  study  of  the  processes  involved  in  solving  a  problem.  Heuristic  reasoning 
is  reasoning  in  the  form  of  general  rules,  hunches,  or  rules  of  thumb  that  are 
approximate  and  generally  have  been  acquired  through  years  of  experience. 
Heuristics  contribute  to  an  ES ' s  power  and  flexibility  and  set  them  apart  from 
traditional  software. 

Heuristic  reasoning  can  provide  direction  to  a  search  process,  thereby  reducing 
the  area  in  the  knowledge  base  that  must  be  searched.  It  can  assist  in  processes 
that  include  eliminating  entire  branches  of  a  search  tree,  selecting  a  general 
path  to  follow,  and  selecting  the  next  node  to  expand. 

Heuristic  reasoning  is  used  in  the  absence  of  more  precise  control  mechanisms 
because  it  uses  rules  of  thumb  that  are  meant  to  produce  acceptable  results  in 
most  cases.  A  drawback  of  heuristic  reasoning  is  that  it  could  lead  a  search 
down  the  wrong  path. 

The  technique  of  programming  used  by  most  ES  programmers  is  referred  to  as 
heuristic  programming.  The  exact  behavior  of  the  system  may  not  be  precisely 
specified  or  predictable  by  the  programmer  (Denning  1986).  These  are  techniques 
that  can  only  be  acquired  from  years  of  experience  in  a  specialist  domain.  This 
type  of  knowledge  tends  to  be  inexact,  uncertain,  and  incomplete.  Most  of  the 
time,  heuristics  offer  reasonable  but  not  necessarily  the  best  solutions. 

2.2.10  Searching 

Occasionally,  more  than  one  rule  may  be  eligible  to  fire  at  the  same  time.  A 
methodology  to  resolve  these  conflicts  must  be  established.  The  most  systematic 
ways  of  resolving  conflicts  are  breadth  first  and  depth  first  searching.  They 
can  be  used  with  either  forward  or  backward  chaining.  Both  of  these  search 
techniques  can  be  used  with  rule-based  systems. 
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2.2.10.1  Breadth  First 


In  a  breadth  first  search,  all  possible  subgoals  on  one  level  are  considered 
before  the  next  level  is  examined  (Adeli  1990).  Increasingly  broad  segments  of 
the  solution  space  are  created  and  each  level  is  checked  for  a  goal  state.  All 
possible  successor  nodes  are  created  from  each  state  by  applying  applicable 
operators  to  the  existing  nodes .  This  ensures  that  the  nodes  at  a  given  level 
are  checked  before  the  next  level  is  addressed.  Figure  2.2-3  shows  the  breadth 
first  search  strategy. 


Action  Has  Been  Applied 

FIGURE  2.2-3.  BREADTH  FIRST  SEARCH  TREE  (Rich  and  Knight  1991) 


2.2.10.2  Depth  First 

Depth  first  searching  entails  pursuing  each  branch  of  a  tree  completely  before 
considering  another  branch.  When  a  goal  or  a  subgoal  matches  the  left  side  of 
a  rule,  all  premises  of  that  rule  are  examined  before  another  subgoal  is 
considered.  This  technique  takes  one  idea  and  pursues  it  until  a  goal  is  reached 
or  the  limit  of  that  branch  of  the  tree  is  reached  (Adeli  1990)  .  The  choice  of 
the  node  used  in  continuing  the  path  may  be  based  on  random  selection.  Figure 
2.2-4  shows  the  depth  first  search  strategy. 

2.2.11  Expert  System  Drawbacks 

The  purpose  of  an  ES  is  to  perform  a  difficult  task  or  resolve  a  substantial 
problem.  It  is  rare  for  an  ES  to  outperform  a  human  expert  and,  if  it  does,  it 
is  because  the  ES  forgets  less  rather  than  remembers  more.  Problems  that  are 
suited  for  ESs  may  require  long  development  and  testing  times  and  can  be  costly. 
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A  number  of  problems  exist  with  ES  methodology,  code,  knowledge  acquisition,  and 
validation  (Coats  1991) : 

•  Methodology  -  The  use  of  IF  THEN  statements  can  be  clumsy  and  unsuitable 

to  express  knowledge  effectively. 


FIGURE  2.2-4.  DEPTH  FIRST  SEARCH  TREE  (Rich  and  Knight  1991) 


■  Code  -  Can  be  difficult  to  understand,  debug,  or  maintain,  and  does  not 
always  provide  adequate  user  interface. 

■  Knowledge  acquisition  -  It  is  not  always  clear  how  to  resolve  conflicting 
views  among  acknowledged  experts . 

■  Validation  -  Methods  for  validation  are  still  being  researched.  Perhaps 
the  basic  question  should  be  "does  the  user  of  the  ES  make  better 
decisions  by  using  it?" 

One  main  concern  about  ESs  is  reliability.  Their  effectiveness  ultimately  relies 
on  the  system  developers.  Very  large  databases  are  hard  to  maintain  and  it  is 
difficult  to  account  for  all  possible  situations. 

Unless  ESs  are  designed  to  provide  reliability  and  maintainability,  they  will  not 
be  capable  of  handling  complex,  real  life  situations.  They  need  to  be  adaptable 
to  deal  with  situations  that  lack  complete  information.  Care  must  be  taken  to 
determine  whether  an  ES  is  suited  to  the  problem. 

There  are  many  influences  in  an  ES  domain  that  may  introduce  uncertainty  into  a 
problem  (Hall  and  Kandel  1992)  : 

■  Characteristics  of  the  solution  to  the  problem 

•  Questions  asked  to  determine  the  solution 

■  Knowledge  acquisition  process 

■  Reasoning  process  of  an  expert 


20-22 


Knowledge  representation  language 


2.2.12  Future  of  Expert  Systems 

Currently,  interest  in  ESs  is  high  and  their  applications  are  increasing. 
Relatively  low  cost  computers  are  being  developed  with  large  memories ,  ample  disk 
space,  and  faster  processing  capabilities.  These  capabilities  will  enhance  the 
possibilities  for  developing  ESs  with  broader  applications. 

ESs  are  most  accepted  if  they  critique  conclusions  or  act  as  advisors.  The  goal 
of  using  an  ES  is  to  improve  productivity  and  the  quality  of  decision  making. 
In  the  future,  powerful  software  and  hardware  may  be  all  that  is  necessary  to 
develop  a  system.  The  ultimate  goal  will  be  to  eliminate  the  role  of  the 
knowledge  engineer  and  enable  the  experts  to  encode  their  own  knowledge  directly 
on  the  computer.  Attention  should  be  focused  on  methods  of  extracting  and 
representing  knowledge  (Weiss  and  Kulikowski  1984) . 

2.2.13  Blackboard  Systems 

A  blackboard  system  is  a  type  of  ES  with  a  slightly  different  architecture.  It 
is  a  multiple  knowledge  source  system  in  which  data  are  shared  between  sources. 
A  knowledge  source  system  is  a  program  whose  knowledge  is  in  a  separate  database 
that  can  be  manipulated  by  the  user.  The  shared  data  provide  communication  and 
cooperation  between  the  experts .  The  rules  have  access  to  all  parts  of  the 
blackboard.  The  blackboard  serves  as  the  input  to  the  rules  and  as  a  record  of 
the  outcome  of  the  rules.  The  blackboard  can  display  the  best  interpretation  of 
a  specific  problem  at  any  given  time. 

The  blackboard  is  the  controller  for  the  entire  structure.  It  records  and 
organizes  solutions  that  are  generated  during  the  problem  solving  process. 
Knowledge  bases  can  communicate  only  through  the  blackboard  and  they  can  generate 
input  to  the  incremental  solution  on  the  blackboard  whenever  they  have  relevant 
information.  There  is  no  priority  or  hierarchy  established  for  knowledge  bases 
to  contribute  to  the  blackboard,  and  the  system  is  not  committed  to  forward  or 
backward  chaining.  It  can  implement  whichever  it  sees  fit. 

The  objective  of  each  knowledge  source  is  to  contribute  information  that  will 
lead  to  the  solution  of  the  problem.  Each  knowledge  source  must  recognize  when 
conditions  are  appropriate  for  its  contribution  to  the  solution.  Each  knowledge 
source  has  a  separate  inference  engine.  Some  architectures  contain  a  scheduler, 
which  chooses  the  next  knowledge  source  to  contribute  data. 

Blackboard  systems  solve  problems  by  dividing  them  into  several  smaller 
subproblems  to  be  solved  separately.  The  problem  dividing  method  influences  how 
well  the  problem  is  solved. 

Advantages  of  a  blackboard  system  include  the  following  (Engelmore  and  Morgan 
1988): 


Many  knowledge  sources  participate  in  forming  a  solution. 
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Each  knowledge  source  has  continual  access  to  the  current  state  of  the 
solution  and  can  contribute  when  needed. 

The  solution  is  built  incrementally. 


■  Both  forward  and  backward  chaining  can  be  used. 

The  classic  blackboard  system  architecture,  as  shown  in  figure  2.2-5,  consists 
of  the  following  (Cohen  1985) : 

■  Several  knowledge  sources  -  Collections  of  production  rules 

•  A  database  or  blackboard 

•  A  scheduler  (optional)  -  An  independent  knowledge  source  that  determines 
which  knowledge  source  should  be  activated  next  to  determine  a  solution 


Knowledge  Source  1  Knowledge  Source  2 


FIGURE  2.2-5.  BLACKBOARD  SYSTEM  ARCHITECTURE 


2.2.13.1  Knowledge  Sources 

Each  knowledge  source  is  an  ES  in  its  own  right,  with  an  internal  structure  which 
can  be  independent  from  other  knowledge  sources.  For  example,  the  structure  can 
be  rule—  or  procedure— based,  or  can  be  homogeneous  or  heterogeneous.  The  form 
of  the  rules  and  the  way  knowledge  is  represented  can  vary  from  source  to  source 
(Engelmore  and  Morgan  1988). 

2.2.13.2  Blackboard  System  Control 

Blackboard  systems  determine  their  own  cognitive  behavior  to  solve  problems 
involving  the  control  of  another  system.  The  system  must  determine  the  problems 
it  will  attempt  to  solve  and  the  knowledge  and  methods  it  will  use  to  solve  the 
problems.  The  system  goal  can  be  choosing  an  area  of  the  blackboard  on  which  to 
concentrate  next,  choosing  a  particular  knowledge  source  to  utilize  next,  or  some 
action  between  the  two.  Whichever  method  is  chosen,  it  must  be  the  most 
efficient  for  the  particular  application.  Selecting  irrelevant  knowledge  sources 
must  be  minimized.  The  control  can  be  integrated  into  the  system  design  or  it 
can  be  a  separate  ES . 

The  blackboard  is  a  record  of  the  hypotheses  reached  and  the  way  they 
interconnect.  Attached  to  each  hypothesis  on  the  blackboard  is  a  measure  of 
likelihood,  which  is  a  measure  of  the  system's  confidence  level  in  the 
hypothesis.  The  likelihoods  of  the  hypotheses  are  updated  continually.  Changes 
made  to  the  blackboard  are  called  events.  These  include  creating  or  deleting 
objects,  changing  values,  and  creating  or  destroying  links  between  objects. 

Blackboard  architecture  is  a  control  structure  design.  The  knowledge  sources  can 
communicate  only  through  the  blackboard,  so  the  events  are  tracked  easily. 
Blackboard  models  contain  a  great  amount  of  information.  Knowledge  sources  are 
not  activated  in  any  particular  order.  They  contribute  hypotheses  in  response 
to  appropriate  situations  on  the  blackboard,  or  the  scheduler  may  decide  when 
they  should  contribute  in  response  to  the  situation.  They  represent  an 
opportunistic  approach  to  solving  problems  that  allows  the  knowledge  bases  to 
contribute  only  when  appropriate  (Cohen  1985) . 

Blackboard  systems  do  not  search  for  solutions ;  rather ,  they  build  an  emerging 
solution  from  all  independent  knowledge  sources.  The  presence  of  many  different, 
independent  knowledge  sources  leads  to  parallel  processing  architecture. 
Knowledge  sources  indicate  to  the  blackboard  when  the  problem  solving  process  is 
terminated,  either  because  an  acceptable  solution  was  found  or  the  knowledge 
sources  are  depleted. 

2.2.13.3  Applications 

Following  are  problem  types  that  are  well  suited  to  being  solved  by  a  blackboard 
system: 

■  Problems  requiring  many  different  and  specialized  types  of  knowledge. 

■  Problems  with  a  natural  hierarchy  of  the  problem  solving  strategy . 
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■  Problems  that  will  benefit  from  solutions  developing  incrementally. 

■  Problems  where  limited  data  are  available  or  for  which  only  a  partial 
solution  is  possible. 

2.2.13.4  Future  of  Blackboard  Systems 

More  research  is  required  to  determine  the  types  of  applications  that  are 
suitable  for  blackboard  systems.  Also,  further  study  of  the  characteristics  of 
particular  types  of  design  choices  for  the  systems  is  needed. 

2 . 3  Fuzzy  Logic 

Traditionally,  vague  or  imprecise  concepts,  such  as  tall,  big,  and  warm,  could 
not  be  represented  on  computers.  Expressions  such  as  these  are  used  in  our 
language  constantly  and  the  ability  to  represent  these  types  of  concepts  is 
helpful  when  dealing  with  set  membership. 

The  strength  of  fuzzy  systems,  and  their  reason  for  being  developed,  was  their 
ability  to  manage  imprecision.  Fuzzy  logic  provides  the  opportunity  to  model 
conditions  that  inherently  are  imprecisely  defined  and  deal  with  statements  that 
are  obscure  or  subject  to  different  interpretations.  It  introduces  a  method  of 
representing  the  degree  to  which  an  object  is  a  member  of  a  particular  set 
(Miyamoto  1990) . 

There  are  many  complex  industrial  processes  that  cannot  be  controlled 
satisfactorily  by  conventional  computing  methods .  The  use  of  rule-based  control 
established  on  approximate  reasoning  provides  an  attractive  alternative.  Fuzzy 
logic  was  developed  for  complex  control  systems  in  which  mathematical  models  were 
difficult  or  impossible  to  create.  Fuzzy  logic  is  an  alternative  to  traditional 
set  memberships.  It  was  developed  to  express  inexact  concepts  such  as  "normal 
height  and  weight."  These  concepts  are  used  frequently  in  everyday  language. 
However,  they  become  a  problem  when  attempts  are  made  to  express  them  using 
binary  distinctions  (Cohen  1985) . 

Fuzzy  models  provide  a  more  flexible  way  to  acquire  accurate  solutions  to 
problems  than  the  rigidness  of  crisp  set  solutions  (Bezdek  1992).  Data  are 
represented  symbolically,  but  they  are  processed  numerically.  Fuzzy  logic  is  a 
precise  and  accurate  method  of  reaching  valid  conclusions  in  control  systems. 
Correctly  implemented,  it  will  sacrifice  only  unnecessary  precision.  Greater 
precision  can  be  achieved  by  increasing  the  number  of  input  and  output  values  and 
increasing  the  number  of  rules  (Brubaker2  1992)  . 

2.3.1  The  Basic  Theory 

There  are  few  situations  that  are  strictly  true  or  false.  Fuzzy  logic  proposes 
that  membership  functions  operate  over  a  range  between  0  and  1,  where  0.0  is 
total  non— membership  and  1.0  is  total  membership.  This  grade  of  membership  is 
particularly  helpful  in  expressing  inexact  concepts  inherent  in  natural  language. 
It  is  a  method  of  representing  analog  processes  on  a  digital  computer. 
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The  membership  functions  usually  are  graphed  by  using  overlapping  triangles; 
however,  other  geometric  shapes  are  possible.  Membership  functions  identify 
regions  that  will  control  the  system.  The  purpose  of  overlapping  shapes  is  to 
allow  for  partial  set  membership.  The  transition  between  being  fully  a  member 
of  the  set  and  not  a  member  at  all  is  gradual.  It  is  possible  for  an  object  to 
be  a  partial  member  of  more  than  one  set  at  the  same  time.  Figure  2.3—1 
illustrates  a  set  of  membership  functions  related  to  throttle  movement.  If  the 
rotational  speed  of  the  throttle  is  -20  radians/second,  it  is  a  member  of  the  set 
"Small  Negative."  The  throttle's  degree  of  membership  within  that  set  is  the 
point  where  a  vertical  line  intersects  with  the  side  of  the  membership  triangle. 
That  would  be  approximately  .6  for  a  speed  of  —20  radians/second. 


Throttle  Movement 

Large  Small  Small  Large 


Fuzzy  systems  are  based  on  the  concept  of  parallel  processing.  Parallel 
processing  allows  large,  complicated  problems  to  be  solved  by  breaking  them  down 
into  smaller  ones.  The  results  of  all  rule  processes  are  unified  and  expressed 
as  a  single  logical  sum.  Compared  to  conventional  control  systems,  fuzzy  systems 
require  fewer  rules  and  reduce  development  time  dramatically . 

Rules  are  in  the  form  of  IF  THEN  statements  that  are  linked  by  ORs .  They  use 
labels  to  describe  the  problem  in  words  and  are  worded  in  a  way  that  is  similar 
to  the  human  thought  process.  For  example,  a  rule  for  controlling  a  flying 
aircraft  may  read  "If  nose  is  low  and  speed  is  high,  then  pull  back  on  yoke." 

One  of  the  main  advantages  of  using  fuzzy  logic  is  that  modifications  are  made 
easily  without  the  need  to  modify  code.  Rules  and  membership  functions  can  be 
added  without  radical  revisions.  Therefore,  designers  can  concentrate  on  the 
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elements  of  the  problem,  as  opposed  to  the  details  of  a  language  such  as  FORTRAN 
or  C  (Williams  1992) . 

Fuzzy  controllers  are  more  flexible  than  conventional  controllers .  If  some 
element,  such  as  information,  is  missing,  a  fuzzy  system  will  adjust  itself 
accordingly. 

2.3.2  Crisp  Logic 

Traditional  or  crisp  logic,  such  as  Boolean,  is  based  on  predefined  thresholds. 
For  instance,  in  Boolean  logic  the  output  and  input  are  always  on  or  off;  there 
are  no  other  states.  There  are  many  situations  that  do  not  conform  to  Boolean 
logic.  Fuzzy  logic  was  developed  for  these  situations  (Lea  1989).  The 
difference  between  crisp  and  fuzzy  logic  can  be  seen  in  figure  2.3—2. 


CRISP  LOGIC 


Height 


FIGURE  2.3-2.  CRISP  VERSUS  FUZZY  LOGIC 


Thresholds  in  fuzzy  logic  are  not  clearly  defined.  Boundaries  overlap  each  other 
and  it  is  possible  for  an  object  to  be  partially  a  member  of  more  than  one  set. 
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2.3.3  Fuzzy  Control 

There  are  three  steps  followed  by  a  fuzzy  controller.  They  are  fuzzification, 
inference,  and  defuzzification. 

2 . 3 . 3 . 1  Fuzzification 

A  fuzzy  system  takes  inputs  and  fuzzifies  them.  Numeric  inputs  are  converted  to 
fuzzy  values,  such  as  small,  fast,  or  warm.  This  is  done  using  degree  of 
membership  functions,  which  are  methods  of  determining  the  extent  to  which  an 
object  is  a  member  of  a  particular  group.  For  example,  a  particular  aircraft  may 
be  considered  both  a  cargo  and  a  passenger  aircraft,  which  would  qualify  it  as 
a  partial  member  of  both  sets.  It  could  be  more  a  member  of  one  than  the  other, 
but  nonetheless  a  member  of  both  to  some  degree.  The  resulting  degree  of 
membership  then  becomes  an  input  to  the  inference  mechanism. 

2. 3. 3. 2  Inference  Mechanism 

Inference  is  the  process  of  inferring  fuzzy  actions  by  applying  fuzzy  inputs  to 
a  rule  base  (Legg  1992).  Fuzzy  actions  include  "pull  back  on  the  yoke,” 
effecting  a  climb  rate  of  100  feet  per  minute.  Rule-based  systems  are  the  most 
popular  type  of  fuzzy  system  at  this  time.  The  inference  process  proceeds  from 
the  conditions  to  the  conclusion  (logical  product)  and  then  to  the  logical  sum 
(Omron  1991).  The  logical  sum  is  a  combination  of  the  results  of  all  the  rules. 
Figure  2.3-3  illustrates  how  a  fuzzy  system  determines  the  control  actions  to  be 
taken  for  a  particular  example.  The  object  is  to  balance  a  stick  in  the  upright 
position  using  seven  rules: 


•  If  the  stick  is  inclined  moderately  to  the  left  and  nearly  still,  move  to 
the  left  quickly. 

•  If  the  stick  is  inclined  slightly  to  the  left  and  falling  slowly,  move  to 
the  left  somewhat  quickly. 

-  If  the  stick  is  inclined  slightly  to  the  left  and  rising  slowly,  do  not 

move  much. 

■  If  the  stick  is  inclined  moderately  to  the  right  and  nearly  still,  move  to 
the  right  quickly. 

■  If  the  stick  is  inclined  slightly  to  the  right  and  falling  slowly,  move  to 
the  right  somewhat  quickly. 

■  If  the  stick  is  inclined  slightly  to  the  right  and  rising  slowly,  do  not 
move  much. 

■  If  the  stick  is  slightly  inclined  and  nearly  still,  do  not  move  much. 

There  are  seven  possible  sets  in  each  of  the  two  position  antecedent  blocks.  In 

the  left/right  position  blocks,  negative  corresponds  to  leaning  towards  the  right 

and  positive  corresponds  to  leaning  towards  the  left.  There  are  3  degrees  of 

membership  in  either  direction:  small,  medium,  and  large.  In  the  falling/rising 
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FIGURE  2.3-3.  OBTAINING  THE  LOGICAL  PRODUCT 


position  blocks ,  negative  corresponds  to  falling  and  positive  to  rising.  There 
are  also  3  degrees  of  membership  in  either  direction:  small,  medium,  and  large. 
Both  position  blocks  have  a  zero  where  the  stick  is  balanced. 

The  line  labeled  "input"  is  one  instance  when  the  stick  is  at  a  certain  point  and 
the  system  is  attempting  to  determine  appropriate  action.  The  point  is  a  member 
of  several  sets.  Therefore,  it  must  be  determined  which  rules  to  apply  to  the 
input.  This  can  be  resolved  by  evaluating  of  which  sets  the  input  is  a  member. 
As  far  as  left/right  position,  at  this  point  the  stick  is  mostly  a  member  of  the 
set  "inclined  moderately  to  the  left."  It  is  also  partially  a  member  of  the  set 
"inclined  slightly  to  the  left."  As  far  as  falling/rising  position,  at  this 
point  the  stick  is  mostly  a  member  of  the  set  "almost  still"  and  partially  a 
member  of  the  set  "falling  slowly." 

By  performing  an  "AND"  operation  on  the  membership  functions,  the  consequent 
blocks  for  each  individual  rule  can  be  determined.  These  values  are  known  as  the 
logical  product.  Figure  2.3-4  shows  the  logical  sum,  which  is  the  total  result 
of  summing  the  consequent  blocks.  This  total  is  defuzzified  by  determining  its 
center  of  gravity,  which,  in  turn,  becomes  the  output  of  the  system.  The  output 
is  generally  applied  to  another  system  to  initiate  an  action. 

The  inference  process  determines  the  degree  of  truth  of  a  rule.  The 
corresponding  action  correlates  to  this  degree  of  truth.  The  inference  system 
is  a  collection  of  fuzzy  IF  THEN  rules.  The  inference  mechanism  uses  a  method 
of  approximate  reasoning  by  which  an  imprecise  conclusion  is  deduced  from  a 
collection  of  imprecise  premises  (Lee  1991) . 

2 . 3 . 3 . 3  Defuzzification 

Defuzzification  is  the  process  of  translating  fuzzy  or  non-crisp  values  into 
values  that  are  crisp  and  clearly  defined.  A  defuzzifier  converts  inference 
process  values  to  a  fixed  value.  Generally,  a  non-fuzzy  control  action,  such  as 
a  fixed  voltage  applied  to  another  system  to  cause  an  action,  is  needed  as  a 
result  of  the  inference  process.  Normally,  more  than  one  rule  applies  to  any 
given  set  of  inputs,  so  the  fuzzy  system  must  combine  the  results  of  several 
rules . 

2.3.4  Control  Systems 

Conventional  control  systems  do  not  have  the  ability  to  self-adapt  to  changes  in 
inputs.  Adaptive  fuzzy  control  systems  can  learn,  explain  their  reasoning,  and 
perform  self-modifications,  when  necessary,  to  produce  more  accurate  results. 
They  can  change  supporting  system  controls,  modify  the  characteristics  of  the 
rules,  modify  the  topology  of  the  fuzzy  sets,  and  change  the  method  of 
defuzzification.  Their  construction  is  similar  to  NN  systems. 

Fuzzy  logic  systems  make  excellent  control  systems.  Controlling  with  IF  THEN 
constructs  is  simpler  than  creating  complex  mathematical  models.  It  is  generally 
easier  to  create  and  understand  fuzzy  control  rules  than  conventional  control 
rules  . 
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FIGURE  2.3-4.  THE  LOGICAL  SUM 
(as  applied  to  the  system  in  figure  2.3-3) 


Fuzzy  logic  systems  are  designed  to  handle  complex  requirements  using  controllers 
that  are  simple,  inexpensive,  and  easy  to  maintain.  Because  fuzzy  systems  use 
intuitive  terms,  complex  systems  are  modeled  easily  and  rapidly.  A  system's 
operational  and  control  laws  are  expressed  linguistically. 

Fuzzy  control  systems  can  be  cheaper,  easier  to  develop,  and  more  accurate  than 
traditional  control  systems.  Also,  they  can  respond  faster  and  consume  less 
power  than  traditional  digital  methods.  These  factors  provide  the  opportunity 
to  bring  products  to  market  faster  and  more  cost  effectively. 
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2.3.5  Probability 


Many  people  confuse  fuzzy  theory  with  probability.  Both  operate  over  the  same 
numeric  range,  where  0.0  represents  false  and  1.0  represents  true.  A  statement 
is  probabilistic  if  it  contains  some  likelihood  or  degree  of  certainty,  i.e. ,  the 
likelihood  that  an  event  will  happen.  Probability  theory  deals  with  the 
uncertainty  that  results  from  random  behavior.  The  difference  between 

probability  and  fuzzy  theory  is  that  probability  states  the  chances  of 
membership,  while  fuzzy  logic  states  the  degree  of  membership  or  the  degree  to 
which  an  event  has  happened.  Fuzzy  theory  deals  with  the  uncertainty  associated 
with  boundary  conditions  (Brubaker1  1992) . 

2.3.6  Parallel  Processing 

Fuzzy  systems  can  use  parallel  processing,  which  allows  multiple  rules  to  be 
processed  simultaneously .  High-speed  processing  can  be  attained  with  hardware 
controllers  because  the  rules  are  processed  independently  of  each  other.  Errors 
will  not  drastically  affect  the  final  result  in  a  parallel  processing 
architecture . 

2.3.7  Hardware 

Fuzzy  systems  do  not  require  massive  computing  power  and  many  applications  do  not 
require  special  fuzzy  Integrated  Circuits  (ICs) .  Normally,  fuzzy  processors  work 
along  with  a  general  purpose  microprocessor,  which  is  needed  for  functions  such 
as  preprocessing  inputs,  keyboard  interaction,  and  support  in  other  input  and 
output  areas . 

Simple  fuzzy  controllers  require  less  than  10  rules,  while  complicated  ones  may 
require  40  or  more.  Some  fuzzy  processors  allow  arbitrary  shapes  for  the 
membership  functions.  Some  limit  the  number  of  shapes  and  others  allow  triangles 
only. 

2.3.8  Designing  a  Fuzzy  System 

Fuzzy  logic  does  not  require  that  a  designer  be  able  to  model  a  control  problem 
mathematically.  All  that  is  required  is  a  firm  understanding  of  the  problem,  a 
basic  understanding  of  physics,  and  a  concept  of  how  the  system  should  behave. 
The  designer  is  not  restricted  to  what  can  be  described  with  equations  (Conner 
1993). 

The  designer  of  a  fuzzy  system  needs  to  identify  a  number  of  elements: 

■  The  input,  output,  and  operations  to  be  performed  on  the  data. 

■  The  control  and  solution  variables,  fuzzy  regions,  and  labels  associated 
with  those  variables. 

■  The  rules  connecting  inputs  to  outputs . 

■  The  method  of  defuzzification. 
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Control  variables  appear  in  the  premise  of  a  rule  (e.g. ,  density,  speed)  and  are 
linked  by  AND.  Determining  these  variables  and  creating  the  rule  base  are  the 
most  difficult  part  of  designing  a  fuzzy  system. 

Labels  are  names  that  are  attached  to  fuzzy  sets  or  membership  functions  (e.g., 
cold,  warm,  hot).  The  shapes  and  slopes  of  membership  functions  can  be  changed 
at  any  time  to  meet  a  design  criterion.  Overlapping  input  functions  guarantees 
that  at  least  two  rules  will  fire  for  any  given  input  and  ensures  a  smooth  output 
curve.  Generally  there  are  an  odd  number  (between  five  and  nine)  of  labels 
(e.g.,  slow,  medium,  fast)  associated  with  each  variable  (Cox  1992).  Membership 
function  sets  should  be  grouped  closely  at  points  where  the  most  activity  in  the 
system  being  monitored  occurs . 

Rules  in  a  fuzzy  system  normally  are  determined  by  an  expert.  They  are  stored 
in  a  rule  base  that  is  similar  to  the  thought  process  that  an  expert  would  use 
to  solve  a  problem.  Because  fuzzy  rules  are  abstract,  they  do  not  need  to  cover 
every  combination  of  cases  that  is  possible.  The  rules  are  defined  by  the 
relation  between  antecedent  and  conclusion. 

2.3.9  Fuzzy  Logic  Advantages 

There  are  a  number  of  misconceptions  associated  with  fuzzy  logic.  Most  of  these 
are  addressed  in  the  following  list  of  advantages  (Cox  1992): 

•  Fuzzy  logic  allows  partial  or  gradual  degrees  of  membership.  The  concept 
that  fuzzy  logic  provides  imprecise  answers  is  a  common  misconception. 

■  Fuzzy  logic  is  different  from  probability.  When  dealing  with  probability, 
the  event  is  clearly  defined.  Fuzzy  logic  is  concerned  with  the  ambiguity 
in  the  description  of  the  event. 

■  Fuzzy  sets  are  easy  to  conceptualize  and  they  are  modeled  in  the  same 
fashion  as  an  expert's  thought  process. 

■  Fuzzy  systems  are  stable,  easily  tuned,  and  can  be  conventionally 
validated.  There  are  fewer  rules  in  fuzzy  systems  than  in  conventional 
control  systems  so  tuning  is  simpler. 

•  Fuzzy  systems  are  different  from,  but  complementary  to,  NNs .  Fuzzy 
systems  are  similar  to  NN  classifiers.  However,  in  a  fuzzy  system  the 
classification  processes  performed  on  the  data  are  more  flexible  for  the 
developer . 


Fuzzy  logic  is  more  than  process  control.  Fuzzy  logic  provides  a  way  of 
representing  and  analyzing  information,  independent  of  particular 
applications . 


Fuzzy  logic  is  a  representation  and  reasoning  process,  not  the  answer  to 
all  AI  problems.  Fuzzy  logic  provides  the  opportunity  to  manage  concepts 
that  are  outside  of  the  realm  of  conventional  Boolean  logic. 
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2.3.10  Fuzzy  Logic  Disadvantages 

Although  fuzzy  logic  is  a  promising  alternative  to  traditional  control  systems, 
there  are  a  number  of  factors  that  need  to  be  addressed: 

■  There  is  not  a  clear  understanding  of  what  applications  are  appropriate 
for  fuzzy  systems  and  how  they  compare  to  traditional  designs. 

■  Fuzzy  systems,  when  optimized  for  speed,  use  an  amount  of  microprocessor 
memory  comparable  to  traditional  control  methods. 

■  There  is  no  formal  design  method  or  system  modification  and  tuning  method 
that  will  eliminate  all  unnecessary  rules  to  find  the  optimum  rule  set. 
The  systems  are  not  analytic  and  system  stability  cannot  be  proven. 

■  Fuzzy  systems  can  be  designed  more  quickly  than  conventional  control 
systems.  However,  they  require  more  simulation  and  tuning  to  optimize 
their  performance.  Fuzzy  systems  may  require  the  same  amount  of 
development  time  as  traditional  systems. 

■  Fuzzy  systems  may  not  be  the  best  alternative  for  all  control  system 
applications  because  they  cannot  prove  closed-loop  system  stability.  This 
requires  much  simulation  and  testing.  If  traditional  control  methods  are 
adequate  for  a  particular  system,  there  is  no  need  to  change  methods.  In 
general,  if  a  system  can  be  defined  using  conventional  control  equations, 
fuzzy  logic  is  not  necessary. 

2.3.11  Applications 

Types  of  systems  that  can  benefit  from  fuzzy  logic  control  include  the  following 
(Omron  1991) : 

■  Non-linear  systems 

■  Systems  with  insufficient  or  unclear  data  input 

■  Systems  that  are  difficult  to  control 

*  Systems  that  benefit  from  or  are  normally  controlled  by  human  intuition 

•  Systems  that  require  adaptive  signal  processing  because  of  dynamic 
environmental  conditions 

■  Systems  with  multiple  inputs  or  conflicting  constraints 

■  Systems  for  which  models  are  unclear  or  difficult  to  define 

Fuzzy  logic  controllers  have  been  used  successfully  in  a  wide  arena  of 
applications.  Items  such  as  car  cruise  controls,  washing  machines,  elevator 
controllers,  vacuum  cleaners,  subway  engine  controllers,  and  security  investment 
systems  have  benefitted  from  fuzzy  systems  (Schwartz  and  Klir  1992). 
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Fuzzy  logic  systems  are  well-suited  to  model  very  large  systems,  natural  or  man¬ 
made,  such  as  weather,  oceans,  economy,  and  stock  markets  (Brubaker  1993)  . 

2.3.12  Future  of  Fuzzy  Logic 

Designing  with  fuzzy  logic  is  regarded  with  skepticism,  in  part  due  to  its  close 
association  with  AI .  Another  reason  for  skepticism  may  be  distrust  of  a  new 
technology  that  is  perceived  as  revolutionary.  Even  its  unusual  name  has  added 
to  the  skepticism. 

However,  when  compared  to  traditional  system  development,  fuzzy  systems  can  be 
designed  more  easily  than  systems  using  a  linear  control  approach.  Also,  the 
basis  of  fuzzy  design  is  easier  to  learn  than  linear  methods. 

Japan  and  Europe  already  utilize  fuzzy  technology  in  practical  systems.  In  the 
United  States,  companies  are  beginning  to  turn  to  fuzzy  logic  as  a  viable  option 
to  solving  many  types  of  problems.  Competition  will  encourage  more  involvement 
in  this  new  technology. 

Replacing  traditional  control  methods  with  fuzzy  systems  may  expand  a  system's 
capabilities.  Just  as  the  microprocessor  revolutionized  the  electronics 
industry,  fuzzy  logic  has  the  potential  to  do  the  same  for  the  control  industry. 

2.4  Neural  Networks 

NNs  are  information  processing  systems  that  can  be  trained  to  solve  problems. 
Artificial  NNs  are  constructed  to  resemble  the  biological  neurons  of  the  brain. 
Hundreds  of  thousands  of  simulated  neurons  are  linked  together  by  synaptic 
connections.  The  structure  of  an  NN  is  shaped  and  reshaped,  depending  on 
associations  among  facts. 

NNs  have  been  described  as  the  second  best  way  of  solving  a  wide  range  of 
problems.  They  are  capable  of  solving  virtually  any  problem  that  involves 
mapping  input  data  to  output  data.  They  produce  relationships,  rather  than 
insight.  The  network  maps  the  array  of  inputs  to  the  array  of  outputs.  NNs  can 
find  acceptable  answers,  although  not  necessarily  the  best  answers,  in  a 
reasonable  amount  of  time  and  for  reasonable  cost.  NNs  can  spare  tedious  and 
expensive  software  design  when  compared  to  other  methods  of  solving  problems. 
NNs  use  information  in  large  databases  to  extract  a  set  of  rules  (Intel  1990) , 

Rapid  progress  is  being  made  in  the  field  of  NN  technology.  Scientists  are 
po  duplicate  the  way  the  brain  makes  inferences  from  incomplete  or 
confusing  information  (Tazelaar  1989).  NNs  can  classify,  store,  recall,  and 
associate  information.  They  can  provide  several  recommendations  for  a  particular 
situation  in  a  few  seconds.  A  machine  that  emulates  the  way  a  brain  operates 
must  work  in  a  parallel  fashion.  There  is  no  centralized  site  of  computing  power 
in  the  brain.  NNs  do  not  have  a  centralized  computing  site  either.  Rather,  each 
individual  computing  site  works  independently. 

NNs  learn  by  association  or  examples ,  rather  than  by  rules  or  mathematical 
formulas  (Lawrence  1991).  Neurocomputers  are  not  programmed,  they  are  trained. 
One  of  the  most  important  objectives  when  developing  an  NN  is  to  determine  the 
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problem  and  the  types  of  data  that  are  available.  Once  this  is  accomplished,  the 
next  step  is  converting  the  information  to  a  form  that  the  NN  can  understand. 

Several  factors  make  NNs  an  attractive  system  choice  for  appropriate 
applications.  These  include  using  incomplete  data  to  produce  approximate 
results;  managing  large  amounts  of  data  quickly  and  efficiently;  and  using 
parallelism,  speed,  and  trainability  for  fault  tolerance  (Obermeier  1989). 
However,  appropriate  applications  for  NNs  still  are  being  researched  and 
clarified.  The  main  application  at  this  point  in  development  is  pattern 
recognition.  NNs  are  best  suited  for  problems  in  which  overall  accuracy  may  be 
less  important  than  estimation  and  flexibility. 

Two  significant  elements  in  NNs  are  learning  and  recall.  Learning  is  the 
adjustment  of  weights  (the  strength  of  the  relationship  between  elements  in  the 
NN  that  are  computing  outputs)  to  store  information.  Recall  is  the  ability  to 
retrieve  the  information  stored  in  the  weights. 

2.4.1  Learning 

NNs  are  data  driven.  While  specific  algorithms  and  problem  definitions  do  not 
have  to  be  formulated,  the  data  must  be  accurate.  If  the  data  contain  errors, 
the  network  will  be  trained  according  to  those  errors  and  will  not  be  capable  of 
producing  accurate  results.  Although  the  success  of  an  NN  depends  on  accurate 
data,  a  clear  physical  understanding  of  the  problem  is  not  required  to  train  the 
NN. 

The  most  popular  learning  method  is  back  propagation.  To  solve  a  problem  with 
a  back  propagation  network,  the  system  requires  many  sample  inputs  with  desired 
outputs.  The  network  learns  by  adjusting  weights.  Back  propagation  compares 
actual  prediction  with  a  correct  prediction  and  uses  the  error  to  change  adaptive 
weights  in  a  direction  that  is  error  reducing  (Carpenter  and  Grossberg  1992). 
Known  information  is  presented  at  the  input,  weighted  values  are  assigned  to  the 
connections,  and  then  the  network  is  run  repeatedly  until  the  output  is  accurate. 
Running  the  network  will  readjust  the  connection  weights.  Data  associations  that 
are  frequent  will  strengthen  useful  neural  couplings,  weaken  negative  couplings 
or  connection  weights,  and  disconnect  unrelated  ones.  The  network  must  be 
trained  on  preselected  inputs  and  outputs  and  then  it  can  be  run  on  new 
information. 

2.4. 1.1  Supervised  Learning 

In  supervised  learning,  trial  and  error  inputs  are  used  to  teach  the  network 
correct  and  incorrect  responses.  Learning  is  accomplished  through  direct 
comparison  of  the  network  output  with  known  correct  answers.  When  an  error 
occurs,  an  error  signal  is  sent  back  through  the  network  and  connection  weights 
are  changed  to  prevent  the  same  error  from  recurring.  This  type  of  learning 
requires  a  priori  knowledge  of  the  results.  Supervised  learning  uses  class 
membership  information.  It  detects  errors  because  of  pattern  misclassif ications . 
A  trainer  supervises  what  is  output  in  reference  to  the  input,  and  the  network 
establishes  a  general  representation  of  the  regularities  of  the  data. 


20-37 


2.4. 1.2  Unsupervised  Learning 

Unsupervised  learning  involves  no  trainer.  Rather,  the  network  organizes  itself 
by  establishing  its  own  classification  of  inputs.  This  is  accomplished  by 
exposure  to  a  number  of  inputs .  Information  used  by  the  system  is  not 
categorized.  Therefore,  unsupervised  learning  cannot  detect  errors  as  well  as 
supervised  learning.  Although  this  method  is  less  computationally  complex,  it 
usually  is  less  accurate. 

2. 4. 1.3  Self-Supervised  Learning 

Self— supervised  learning  takes  place  without  an  external  monitor.  There  is  a 
feedback  device  that  detects  errors  and  adjusts  weights  accordingly.  This  is  a 
combination  of  supervised  and  unsupervised  learning  techniques. 

2.4.2  Transfer  Functions 

The  transfer  function  defines  the  value  of  the  output  signal  (Lawrence  1991). 
The  transfer  function  is  a  nonlinear  function  performed  on  the  output  of  an  NN . 
Different  types  of  NNs  use  different  nonlinearities,  depending  on  the  type  of 
output  desired.  They  are  methods  of  limiting  the  output.  There  are  five 
transfer  functions  regularly  employed  by  NNs:  linear,  step,  ramp,  sigmoid,  and 
gaussian.  The  differences  among  them  have  to  do  with  the  shape  of  the  function. 
An  NN  system  designer  will  choose  the  shape  most  appropriate  for  the  particular 
application. 

2.4.3  Construction 

A  biological  neuron  consists  of  axons  (output),  dendrites  (input),  and  synapses 
(pathways  for  transmission  of  impulses  from  one  neuron  to  another) .  In  an 
artificial  NN,  wires  are  used  for  axons  and  dendrites,  and  resistors  with 
weighted  values  are  used  for  the  synapses  (Obermeier  1989).  NNs  consist  of 
layers  of  Processing  Elements  (PEs) ,  weighted  connections,  and  threshold 
functions.  Figure  2.4-1  shows  the  NN  architecture. 

The  brain  is  an  extremely  complex  system  and  artificial  NNs  are  comparatively 
simple.  In  designing  an  NN,  scientists  are  attempting  to  duplicate  many  of  the 
desirable  features  found  in  the  brain,  such  as  fault  tolerance,  flexibility,  and 
parallel  processing  (Hertz,  Krogh,  and  Palmer  1991).  Figure  2.4-2  shows  the 
difference  between  artificial  and  biological  neurons. 

The  PE,  or  neuron,  is  the  part  of  the  NN  where  computing  is  performed  (Simpson 
1991) .  NNs  operate  efficiently  in  parallel  because  each  PE  operates 
independently  of  the  others.  All  PEs  operate  in  parallel,  as  opposed  to 
traditional  digital  processors,  which  perform  sequential  arithmetic  and/or 
symbolic  information  processing  (Krogmann  1991).  A  large  number  of 
interconnected  neurons  work  toward  a  common  goal.  A  PE  depends  on  adjoining 
inputs  from  abutting  connections  to  produce  its  outputs. 

A  network  achieves  stability,  or  converges,  when  the  weight  values  associated 
with  the  PEs  have  finished  changing.  Networks  normally  converge,  with  training, 
to  a  stable  solution. 
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FIGURE  2.4-1.  NEURAL  NETWORK 


2. 4. 3.1  Network  Connections 

The  way  in  which  neurons  are  connected  determines  the  type  of  processing  that 
will  occur.  A  connection  is  a  line  of  communication  that  goes  from  a  sending 
neuron  to  a  receiving  neuron.  Connections  may  go  between  the  layers  of  neurons 
in  an  interlayer  or  intralayer  fashion.  The  connections  modulate  the  information 
flow  between  the  PEs .  The  strength  of  the  connections  between  neurons  is  a 
weight.  A  weight  controls  the  strength  of  the  incoming  signal  to  the  neuron. 
The  degree  of  cell  stimulation  is  determined  by  the  frequency  of  the  signals 
coming  into  the  cell  (Krogmann  1991) .  The  collection  of  weights  for  the  entire 
network  is  called  a  weight  matrix.  The  knowledge  of  the  network  is  distributed 
across  the  interconnections  of  neurons.  Weights  can  be  positive,  negative,  or 
zero.  Feedback  occurs  when  the  output  of  one  layer  goes  to  the  input  of  the 
previous  or  same  layer. 

The  network  interconnections  can  be  changed  by  generating  new  connections,  losing 
existing  interconnections,  and  changing  existing  interconnection  weights. 

Detailed  past  information  is  stored  in  the  connection  weights  of  the  network  and 
is  represented  by  a  matrix. 
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FIGURE  2.4-2.  BIOLOGICAL  AND  ARTIFICIAL  NEURONS 


2. 4. 3. 2  Neural  Network  Layers 

layer  is  a  collection  of  neurons  in  an  NN  that  is  separate  from  other 
collections.  Neurons  are  located  in  input,  output,  or  hidden  layers.  Hidden 
layer  neurons  connect  only  to  other  neurons .  Input  and  output  layer  neurons 
connect  to  the  environment  outside  of  the  NN .  Three  layers  are  sufficient  for 
any  arbitrary  non-linear  mapping. 

The  input  layer  does  not  process  data;  it  passes  the  inputs  to  the  hidden  layer. 
The  hidden  and  output  layers  are  the  processing  layers. 

2.4.4  Designing  a  System 

Following  are  some  issues  that  must  be  resolved  before  an  NN  can  be  successfully 
implemented  (Hertz,  Krogh,  and  Palmer  1991): 

■  Architecture  -  How  many  units  and  layers  are  necessary?  How  should  they 

be  organized  and  what  type  of  updating  should  be  used? 
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•  Training  -  How  many  examples  should  be  used?  How  many  times  should  the 

network  cycle  through  the  examples?  Should  learning  be  supervised  or 
unsupervised,  real-time  or  non  real-time? 

■  Network  type  -  How  much  can  the  network  learn?  How  fast  and  robust  is  the 
network?  How  well  can  it  generalize? 

■  Network  hardware  -  What  are  the  advantages  and  disadvantages  of  network 
hardware,  and  how  does  the  hardware  compare  to  software  simulation. 

2.4.5  Applications 

NNs  are  used  to  solve  problems  that  digital  methods  cannot  handle  efficiently. 
They  can  solve  nonlinear  problems  because  the  neurons  are  highly  interconnected 
and  provide  a  close  nonlinear  relation  between  the  input  and  output.  Also,  they 
can  handle  large  amounts  of  data.  Problems  that  involve  complex  mathematics 
and/or  require  quick,  nonexact  answers  are  suited  for  NNs.  Also  well— suited  for 
NNs  are  problems  that  include  many  examples ,  but  no  rules  or  formulas .  An 
advantage  of  NNs  over  rule— based  programming  is  that  if  the  process  being 
analyzed  changes,  all  that  needs  to  be  done  is  to  collect  new  examples  and 
retrain  the  NN.  There  is  no  need  to  determine  new  formulas  and  rewrite  software. 

Some  of  the  operations  that  NNs  perform  include  classification,  pattern  matching, 
pattern  completion,  and  signal  noise  removal.  The  main  application  is  pattern 
recognition.  NNs  can  recognize  patterns  even  when  the  data  are  noisy,  ambiguous, 
distorted,  or  variable. 

Following  are  characteristics  of  appropriate  problems  for  NNs: 

•  The  algorithm  to  solve  the  problem  is  unknown  or  expensive  to  develop. 

■  Rules  to  solve  the  problem  are  unknown  or  difficult  to  define. 

■  Large  amounts  of  data  are  available  for  the  problem  at  hand. 

NNs,  however,  are  not  suitable  for  handling  all  types  of  problems.  They  are  not 
suited  for  number  processing,  therefore,  they  should  not  replace  data-based  or 
knowledge-based  processing.  Traditional  digital  computers  are  better  suited  for 
problems  that  require  accuracy  and  computational  power.  NNs  are  not  an  extension 
of  sequential  computers.  Problems  that  are  linear  should  use  linear  problem 
solving  techniques. 

2.4.6  Future  of  Neural  Networks 

Table  2.4-1  illustrates  some  of  the  needs  and  future  applications  of  NNs. 

2.5  Integrated  AI  Systems 

2.5.1  Fuzzy  Logic  Integrated  with  Neural  Networks 

Integrating  NNs  with  other  technologies  may  have  considerable  potential.  The 
difference  between  fuzzy  and  neural  systems  is  in  the  way  they  represent 
knowledge.  By  adding  fuzziness  to  an  NN,  the  designer  can  describe  boundaries 
more  generally,  describe  input  more  vaguely,  and  maintain  better  control.  Few 
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systems  are  capable  of  creating  fuzzy  decision  rules  and  modifying  them  on  the 
basis  of  past  experiences.  The  synthesis  of  fuzzy  logic  and  NNs  has  control  and 
image  processing  applications. 

2.5.2  Expert  Systems  Integrated  with  Neural  Networks 

ESs  are  suited  for  problems  that  are  well-defined  and  specific  to  a  certain 
domain,  while  NNs  can  deal  with  a  broader  and  more  general  range  of  problems. 
ES  implementation  tends  to  be  a  long  process ,  while  NNs  can  provide  answers 
quickly  and  with  acceptable  accuracy. 

The  goal  of  integrating  these  two  methods  is  to  extract  features  from  NNs  and  ESs 
to  create  a  system  that  can  provide  the  advantages  of  both.  The  advantages 
include  reasoning  for  collecting  data  and  fast,  general  answers  or  more  accurate, 
slower  ones.  Also,  ESs  can  analyze  and  validate  an  NN's  output. 


TABLE  2.4-1.  FUTURE  EXPECTATIONS  FOR  NEURAL  NETWORKS 


Needs 

■  More  powerful  serial  digital  computers 

•  Better  understanding  of  brain  operation 

■  Developments  in  hardware  that  will  support  NN  speed  and  storage 

requirements  _ 

Applications 

•  NNs  integrated  with  ESs 

■  Space  exploration 

■  Nuclear  power 

■  Military 

■  Applications  where  an  NN's  graceful  degradation  would  allow 
operations  to  continue  under  circumstances  in  which  conventional 
computers  would  cease  operations 

■  Any  application  that  would  benefit  from  the  unique  pattern 

recognition  and  identification  capabilities  of  NNs _ 


There  are  three  steps  involved  in  an  ES/NN  problem  solving  process:  data 
collection,  data  evaluation,  and  conclusion  analysis.  Data  collection  and 
conclusion  analysis  are  tasks  best  suited  for  the  ES  component.  ESs  are  designed 
for  user  interaction,  such  as  collecting  inputs  and  producing  outputs.  Data 
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evaluation  is  a  task  well-suited  for  the  NN  part  of  the  system,  because  it  deals 
with  imprecision  and  learning. 

2.5.3  Expert  Systems  Integrated  with  Fuzzy  Logic 

A  fuzzy  ES  is  an  ES  that  incorporates  fuzzy  sets  and  fuzzy  logic  into  its 
reasoning  process  and  knowledge  representation.  This  allows  a  wide  range  of 
problems  to  be  solved  with  the  benefits  of  ES  techniques  and  fuzzy  theory.  Fuzzy 
ESs  can  be  user  friendly,  efficient,  and  compact. 

In  some  areas,  fuzzy  methods  can  replace  traditional  methods  altogether.  In  some 
applications,  fuzzy  techniques  can  augment  other  methods. 

Inference  procedures  that  can  handle  imprecise  or  vague  knowledge  are  beginning 
to  be  recognized  as  useful  problem  solving  methods.  When  developing  the  rule 
base  in  an  ES ,  experts  often  express  their  knowledge  in  vague  terms.  An  ES  can 
handle  imprecision  in  controlled  amounts.  When  problems  have  uncertainty,  fuzzy 
logic  is  the  desired  choice  of  methods.  It  has  been  employed  successfully  in 
several  ESs.  Fuzzy  ESs  use  human-like  behavior  to  handle  concepts  and  reasoning. 

Fuzzy  logic  is  especially  helpful  for  managing  the  rule  base  of  an  ES .  It  is 
nearly  impossible  to  account  for  all  possible  combinations  of  antecedents  and 
conclusions  for  any  particular  problem,  especially  large,  complex  problems.  The 
logic  needs  to  be  traced,  step  by  step,  from  all  starting  points  to  possible 
solutions.  This  task  can  be  nearly  impossible  when  dealing  with  even  medium¬ 
sized  knowledge  bases.  Fuzzy  concepts,  however,  allow  all  combinations  to  be 
covered  using  fewer  rules.  Some  action  always  will  be  taken,  even  if  an  exact 
match  of  the  antecedent  is  achieved  (Togai  and  Watanabe  1992)  . 
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3.  ARTIFICIAL  INTELLIGENCE  AND  EXPERT  SYSTEM  DEVELOPMENT 


This  section  examines  the  software,  hardware,  and  development  environment  related 
to  the  AI  field.  The  software  and  hardware  development  tools  and  hardware 
devices  discussed  in  this  section  are  mentioned  as  a  sampling  of  available  tools , 
systems,  and  devices,  and  not  intended  to  be  a  complete  listing  of  what  is 
available . 

Complete  solutions  for  Al-based  problems  are  not  available  exclusively  in  silicon 
at  this  time.  However,  in  the  future  this  could  change  as  technology  continues 
to  drive  IC  densities  to  greater  levels  of  complexity  and  AI  technology  continues 
to  mature.  Whether  it  is  a  microprocessor  with  an  Al-based  native  language,  or 
an  NN  IC,  the  device  is  generally  viewed  as  part  of  a  larger  system.  Current 
applications  for  Al-based  devices  are  proposed  for  automating  and  assisting  human 
or  machine  performance.  Al-based  devices  typically  function  as  embedded 
processors . 

Whether  one  is  concerned  only  with  hardware  devices,  or  only  with  developing  an 
AI— based  software  program,  tools  are  required.  Many  issues  should  be  examined 
when  developers  are  considering  a  tool  for  building  an  AI— based  system.  There 
are  many  tools  available,  but  the  suitability  of  a  tool  should  be  examined 
carefully.  Tools  may  be  chosen  by  financial  motivation,  the  developer's 
familiarity  with  the  tool,  or  the  tool's  compatibility  with  the  developer's 
hardware.  In  some  cases,  tools  are  developed  and  applications  are  then 
fabricated  to  test  them  (Waterman  1986) . 

3.1  Software  for  Artificial  Intelligence  Applications 

There  are  many  computer  languages  available  for  the  program  developer. 
Programming  large  applications  in  assembly  language  (a  low  level  language  using 
mnemonics  to  represent  the  processor's  machine  code)  is  inefficient,  costly,  and 
difficult  to  debug  since  there  is  a  large  body  of  code  to  review.  Higher  level 
languages  and  other  development  tools  have  been  created  to  allow  the  programmer 
to  develop  and  debug  code  rapidly. 

Along  with  the  creation  of  languages  and  tools  came  increases  in  the  complexity 
of  digital  systems  and  the  corresponding  complexity  of  programs  required  to 
control  them.  Languages  created  specifically  for  the  purpose  of  programming  Al- 
based  systems  include  LISt  Processor  (LISP)  and  PROgramming  in  LOGic  (PROLOG). 
Other  high  level  languages  have  been  used  as  well. 

Shaw2  (1993)  provides  a  list  of  AI  language  products  and  tools  available, 
including  LISP,  Scheme,  Rete ,  Logo,  and  PROLOG  products.  Some  of  the  common  AI- 
specific  programming  languages  are  presented  briefly  in  the  following  sections. 


20-45 


3.1.1  List  Processor 


LISP  is  called  the  native  language  of  AI  (Charniak  and  McDermott  1985).  Many- 
different  versions  of  LISP  have  been  developed.  COMMON  LISP  was  developed  in  an 
attempt  to  focus  these  versions  in  a  common  direction  and  enhance  the  language 
portability . 

Users  can  change  the  syntax  of  the  LISP  language  to  suit  themselves.  It  is 
symbol,  instead  of  number,  oriented.  Data  structures  are  easily  constructed  in 
LISP.  LISP  is  also  procedure  oriented.  Nested  subroutines  are  used  to  organize 
and  control  program  execution. 

LISP  was  designed  for  manipulating  symbols,  as  opposed  to  numeric  data.  The 
ability  to  manipulate  symbols  has  made  LISP  popular  among  the  research  community . 
Programming  in  LISP  provides  certain  benefits: 

•  An  interactive  programming  environment 

■  Incremental  compilation 

■  Customization  based  on  the  application 

■  Automatic  memory  management  features 

3.1.2  Programming  in  Logic 

PROLOG  is  a  programming  language  based  on  mathematical  logic.  Finding  a  solution 
is  a  matter  of  deducing  it  from  the  facts.  PROLOG  has  been  successful  in  natural 
language  processing  applications  and  has  been  an  important  language  base  for  the 
study  of  parallel  programming  techniques  (Murphy  1993). 

PROLOG  software  packages  come  in  interpreted  and  compiled  versions,  and  allow  for 
the  use  of  recursion.  PROLOG  is  not  suited  for  number  crunching  or  interfacing 
to  real-time  data  collection  systems  (Murphy  1993).  Programming  is  often 
performed  using  two  languages  to  handle  the  required  functionality  efficiently. 
For  instance,  C  may  be  combined  with  PROLOG  to  be  effective  in  a  program  with  a 
mixture  of  numeric  computation  and  logic. 

3.1.3  Tools  for  the  Expert  System 

ES  shells  are  used  to  develop  knowledge  base  systems.  An  ES  shell  provides  the 
human  interface  for  programming  an  ES .  Shells  limit  development  flexibility,  but 
save  development  time  by  providing  a  development  environment  specifically  suited 
to  ES  programming.  Shells  provide  a  method  for  representing  and  storing  domain 
knowledge  in  the  form  of  rules  and  provide  an  inference  engine  for  making 
decisions  based  on  that  knowledge. 

For  ESs ,  programming  languages  and  ES  shells  are  used  for  development.  Table 
3.1-1  (Waterman  1986)  summarizes  some  of  the  advantages  and  disadvantages  of 
using  an  ES  shell,  as  opposed  to  a  programming  language,  to  implement  an  ES . 

3.1.4  Fuzzy  Languages  for  Development 

Language  tools  exist  for  generating  assembly  code  for  popular  microprocessors 
based  on  a  language  translation  from  a  predefined  set  of  fuzzy  instructions. 
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These  tools  operate  on  the  fuzzy  instruction  set  and  convert  each  instruction 
into  a  sequence  of  assembly  code  mnemonics  for  the  selected  microprocessor. 
Tools  also  exist  for  fuzzy  processors  with  a  fuzzy-based  native  language.  These 
tools  define  a  particular  fuzzy  assembly  language  that  requires  no  conversion 
process . 

Instructions  are  converted  from  assembly  code  directly  into  executable  machine 
code  for  the  fuzzy  controller. 


TABLE  3.1-1.  COMPARISON  OF  EXPERT  SYSTEM  AND  PROGRAMMING 
LANGUAGE  DEVELOPMENT  METHODS 


Expert  Systems 

Programming  Languages 

Advantages 

Development  is  easier, 
faster,  and,  therefore, 
less  costly 

Greater  flexibility 

More  guidelines  and 
mechanisms  for  representing 
and  accessing  the  knowledge 
base 

Product  may  more  closely 
match  the  problem  being 
solved 

Disadvantages 

Less  flexibility 

Developer  will  need  to 
design  the  knowledge  base 
and  the  inference  engine 

May  lack  efficiency 

Takes  longer  to  develop 
application 

Some  tools  also  generate  C  code  from  the  translated  fuzzy  instruction  set.  The 
C  code  can  be  compiled  and  executed  on  a  number  of  processors.  These  tools  allow 
the  developer  to  program  using  a  fuzzy  command  set.  A  translation  is  then 
performed  to  create  high-level  C  code.  The  C  code  can  be  compiled  and  executed 
on  numerous  processors  and  systems. 

3.1.5  Other  Languages  and  Tools 

Procedures,  standards,  and  development  methodologies  have  been  produced  for  the 
use  of  conventional  programming  languages  in  digital  avionic  systems,  but  do  not 
exist  for  AI  specific  languages.  Since  this  is  so,  some  of  the  proposed  avionic 
applications  of  AI— based  systems  have  focused  on  the  use  of  conventional  software 
for  the  implementation.  In  the  military  community,  the  use  of  Ada  has  been 
mandated  for  future  avionics  and  space  applications. 

A  goal  for  large  scale  development  of  Al-based  systems  should  be  to  automate  as 
much  of  the  process  as  possible  by  developing  tools  or  by  using  tools  that  are 
available  and  suitable.  Tools  focused  on  automating  the  design  process  decrease 
the  development  cycle  time.  They  also  reduce  the  number  of  human  errors. 
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3. 1.5.1  Boeing  Advanced  Blackboard  Ada  Generation  Environment 

One  of  the  tools  being  developed  at  Boeing  is  the  Boeing  Advanced  BlackBoard  Ada 
Generation  Environment  (BABBAGE) .  This  tool  is  designed  to  be  a  complete  work 
environment  for  the  development  of  AI— based  systems . 

Leeper  (1990)  indicates  that  the  need  for  such  a  tool  set  arose  due  to  the 
following: 

■  Reluctance  by  AI  programmers  to  deal  with  strongly  "typed"  languages,  such 
as  Ada 

■  Necessity  to  reduce  syntactic  and  semantic  coding  errors 

■  Inflexibility  of  software  interfaces  to  the  AI  engine 

■  Requirement  to  eliminate  laxity  in  programming  loosely  typed  languages 

3. 1.5. 2  CLIPS  Expert  System  Shell 

CLIPS  is  a  knowledge  base  tool  developed  at  NASA  Johnson  Space  Flight  Center. 
It  was  written  in  American  National  Standards  Institute  (ANSI)  C.  It  is  an  ES 
shell  that  has  a  LISP-like  syntax.  Some  of  the  features  of  CLIPS  include  (Daysh, 

et  al.  1991): 

•  Use  of  variables  for  control  of  rules  and  facts 

■  Capability  to  perform  LISP-like  calculations  within  rules 

■  Ability  to  prioritize  the  rule  firing  sequence 

■  Provision  of  commands  to  aid  in  debugging 

3. 1.5. 3  FORTRAN  Library  for  Expert  Systems 

The  FORTRAN  Library  for  EXpert  systems  (FLEX)  was  developed  by  the  Royal 
Aerospace  Establishment  (RAE) .  It  consists  of  a  library  of  FORTRAN  77 
subroutines  that  allows  FORTRAN  programs  to  interface  with  ESs.  In  addition  to 
the  subroutines,  FLEX  supports  a  separate  knowledge  base  and  provides  explanation 
facilities  (Daysh,  et  al .  1991).  Butler  and  Corbin  (1988)  give  further  details 
on  the  features  and  operation  of  FLEX. 

3.2  Artificial  Intelligence  and  Expert  Systems  Hardware 

Development  of  AI  applications  based  on  LISP  began  on  an  IBM  709.  A  high- 
performance  application,  MacLisp,  appeared  on  the  PDP-10 .  Other  special  purpose 
LISP  machines  began  to  appear,  such  as  the  Xerox  PARC  and  Symbolics  systems. 
Now,  systems  implementing  Al-based  applications  are  being  developed  using  generic 
systems  with  compilers  for  the  particular  task  at  hand.  Development  environments 
exist  for  mainframes,  workstations,  and  PCs. 

Target  environments  for  implementations  vary  widely.  For  instance,  one  AI 
implementation  was  performed  using  a  MIL-STD-1750A  processor,  64k  memory,  and  the 
Ada  programming  language. 
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Recently,  however,  great  strides  have  been  made  in  the  development  of  silicon- 
based  devices  that  implement  specific  AI  technologies.  Most  notable  are  high¬ 
speed  and  dense  NNs  and  very  fast  fuzzy  logic  processors. 

3.2.1  Neural  Processors 

NNs  are  implemented  in  both  software  and  hardware.  A  software-implemented  NN  may 
be  a  standalone  or  an  add-on  software  package  which  can  run  on  a  number  of 
computer  platforms.  Inputs  to  the  NN,  as  well  as  the  weights,  are  stored  in 
computer  memory.  The  software  performs  processing  based  on  a  fixed  or  user- 
selectable  algorithm.  The  output  state  is  then  determined  based  on  the  inputs, 
NN  weights,  and  calculation  method.  Typically,  users  adjust  the  weights,  choose 
the  calculation  method,  and  train  the  network.  Software-based  NNs  may  derive 
inputs  from  various  external  or  internal  sources,  such  as  spreadsheets, 
databases,  and  custom  input  files.  Where  higher  levels  of  performance  are 
necessary,  NNs  are  implemented  using  hardware  accelerators  or  NN  ICs . 

Neural  processors  have  been  the  focus  of  significant  research  recently.  The 
following  sections  examine  some  of  the  silicon-based  AI  hardware  that  is  either 
currently  available  or  in  some  phase  of  research  and  development. 

3. 2. 1.1  80170NX  Electrically  Trainable  Analog  Neural  Network 

The  80170NX  Electrically  Trainable  Analog  Neural  Network  (ETANN)  is  an 
Electrically  Erasable  Programmable  Read  Only  Memory  (EEPROM) -based  IC  available 
in  a  5-volt  pin  grid  array  (PGA)  package  with  208  pins.  It  is  both  Transistor- 
Transistor  Logic  (TTL)  and  Complimentary  Metal-Oxide  Semiconductor  (CMOS) 
compatible  at  the  interface  connections  (Intel1  1990)  . 

The  ETANN  is  internally  configured  with  64  neurons  and  10,240  synapses.  Inputs 
to  the  ETANN  are  both  internal  (feedback)  and  external.  The  device  feedback 
inputs  can  also  be  used  as  device  inputs,  providing  up  to  128  total  inputs. 
Performance  claimed  for  this  device  is  greater  than  2  x  109  connections  per 
second. 

The  use  of  EEPROM  makes  the  device  weights  reprogrammable  and  nonvolatile. 
Individual  weights  and  neurons  are  addressed  using  the  device's  address  lines, 
and  the  weights  are  stored  internally.  A  Learn  Control  pin  allows  the  NN  to 
operate  in  a  learning  mode,  which  causes  the  values  of  the  synapse  weights  to 
change . 

NNs  are  typically  made  for  cascade  operation.  The  outputs  and  inputs  are  voltage 
and  current  compatible  so  that  the  output  from  the  first  device  connects  directly 
to  the  input  of  the  second  device.  Connections  between  ETANN  devices  can  be  made 
using  either  a  bus  interconnection  scheme  or  direct  pin-to-pin  wiring  (Intel1 
1990) . 

3. 2. 1.2  NilOOO  Neural  Network  Integrated  Circuit 

One  of  the  programs  of  the  Advanced  Research  Projects  Agency  (ARPA  [formerly 
DARPA])  is  the  Artificial  Neural  Network  Technology  program.  One  of  the 
directions  of  this  program  is  to  fund  development  and  applications  of  the  NilOOO. 
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Development  is  being  performed  by  Intel  and  Nestor.  Lockheed  Missiles  and  Space 
Company  is  the  first  Beta  test  site  for  this  device  (Coleman  1993).  The  NilOOO 
design  contains  1024  artificial  neurons,  implemented  using  3.7  million 
transistors.  Processing  speed  for  the  device  is  claimed  to  be  20  billion  integer 
operations  per  second. 

3. 2. 1.3  RN-200  Neurocomputer 

This  Neurocomputer  IC  was  designed  by  Ricoh  of  Menlo  Park,  California.  It  is 
fabricated  using  CMOS  technology  as  a  gate  array  device  with  200,000  gates,  using 
.8— /im  line  widths.  A  total  of  256  synapses  are  implemented  on  the  IC.  It 
consists  of  three  layers:  the  input,  processor,  and  output  layers.  The  neuron 
update  rate  is  claimed  to  be  1.5  billion  per  second  when  the  device  is  running 
at  a  processing  speed  of  12  MHz  (Normile  1992) . 

3. 2. 1.4  M1718  Digital  Neural  Network 

The  M1718  Digital  Neural  Network  is  produced  by  Hughes  Semiconductor.  This 
device  utilizes  static  CMOS  memory  internally.  It  contains  1024  weights,  which 
support  32  8-bit  inputs  connected  to  32  internal  nodes.  The  M1718  is  TTL- 
compatible  with  an  8-bit  bus  interface.  A  throughput  of  100,000  patterns  per 
second  is  claimed  by  the  manufacturer.  The  devices  are  gangable  so  that  networks 
of  varying  sizes  can  be  created. 

3. 2. 1.5  Optical  Neural  Computing  Integrated  Circuit 

A  prototype  optical  neural  computing  IC  has  been  produced  (Mitsubishi  Electric 
1992).  The  design,  shown  in  figure  3.2-1,  uses  eight  long  and  narrow  Light 
Emitting  Diodes  (LEDs)  on  top  of  an  8  x  8  array  of  photodetectors.  Weighting  is 


LED  Element 


FIGURE  3.2-1.  OPTICAL  NEURAL  COMPUTING  INTEGRATED  CIRCUIT 

(Mitsubishi  1992) 
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performed  by  adjusting  the  sensitivity  of  the  detectors.  This  IC  is  fabricated 
on  a  gallium  arsenide  (GaAs)  substrate  that  measures  6  mm  square.  It  learns  at 
a  rate  of  600  million  connection  updates  per  second. 

3. 2. 1.6  Neural  Accelerator  Hardware 

Neural  accelerator  hardware  implements  an  NN  on  a  printed  circuit  card  that  is 
hosted  on  a  computer  system  such  as  a  PC.  Neural  accelerators  use  high-speed 
Reduced  Instruction  Set  Computer  (RISC)  processors,  architecture,  and  other 
supporting  hardware  to  attain  fast  connection  rates,  as  compared  to  software- 
implemented  or  NN  ICs. 

3.2.2  Design  Considerations  for  Fuzzy  Logic 

In  cases  where  a  fuzzy  logic  solution  matches  the  intended  application,  designers 
can  achieve  significant  advantages.  Using  fuzzy  logic,  system  designers  can 
realize  lower  development  costs,  superior  features,  and  better  end  product 
performance.  Products  can  be  brought  to  market  faster  and  more  cost-effectively. 

There  are  considerations  to  be  made  in  the  choice  of  an  architecture  for  a  fuzzy 
logic-based  system.  The  proposed  application  can  dictate  the  hardware  required. 
Conventional  Central  Processing  Units  (CPUs)  are  sometimes  used  where  execution 
speed  is  not  a  factor.  Where  speed  is  a  factor,  the  choice  of  the  CPU  can  have 
significant  impact  on  system  performance. 

A  CPU  architecture  containing  a  large  register  file  is  helpful.  This  is 
necessary  if  all  terms  are  to  exist  within  the  CPU.  A  CPU  containing  a  large 
register  file  greatly  reduces  the  number  of  external  memory  accesses  that  are 
required  during  program  execution. 

Applications  vary  widely  with  respect  to  the  number  of  rules  required  and  the 
speed  of  the  CPU  which  executes  those  rules.  Some  speed-critical  applications 
may  require  only  a  few  rules,  but  a  very  fast  CPU  to  keep  in  time  with  the 
controlled  system.  A  high-speed  motor  control  application  is  one  example  where 
speed  is  essential,  but  the  number  of  rules  applied  can  be  limited. 

Automotive  applications  require  high  speed  and  can  be  complex.  Antilock  braking 
systems,  climate  control,  and  transmission  control  are  examples  of  applications 
that  may  be  suited  to  the  use  of  fuzzy  logic.  High-speed  applications  will 
require  the  use  of  special  fuzzy  logic  ICs.  These  ICs  may  be  fast  enough  to 
control  several  tasks  simultaneously.  Fuzzy  controllers  execute  rules  10  to  100 
times  faster  than  general  purpose  CPUs  (Legg  1993) . 

3. 2. 2.1  Fuzzy  Coprocessors 

Fuzzy  Coprocessors  and  "engines"  are  also  produced  by  a  number  of  manufacturers. 
Fuzzy  Coprocessors  are  intended  to  interface  to  various  microprocessors  so  that 
fuzzy  instructions  can  be  performed  rapidly,  by  a  device  tailored  for  them.  They 
execute  instructions  specifically  targeted  for  them  out  of  the  CPU  instruction 
stream.  Fuzzy  engines  are  designed  to  be  used  as  a  peripheral  device  within  a 
CPU,  or  as  a  basic  building  block  for  an  Application  Specific  Integrated  Circuit 
(ASIC).  The  ASIC  elements  can  be  combined  to  form  various  designs: 
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■  ASICs  with  fuzzy  capability  and  custom  logic 

•  ASICs  that  combine  fuzzy  processing  on  the  same  IC  as  a  conventional  CPU 

•  ASICs  that  are  designed  to  function  as  coprocessors 

Some  of  the  fuzzy  engines  and  coprocessors  that  are  under  development  or  are  in 

production  are  discussed  in  the  following  sections . 

3. 2. 2. 1.1  FC110  Fuzzy  Processor 

The  FC110  Fuzzy  Processor  was  developed  by  Togai  InfraLogic,  Incorporated.  The 
FC110  is  called  an  "8-bit  RISC  processor  optimized  for  fuzzy  logic . "  It  is 
designed  for  processing  large  rule  bases  and  allows  user— defined  membership 
functions  (see  section  2.3)  with  arbitrary  shapes  (Legg  1993). 

3. 2. 2. 1.2  SAE  81C99  Coprocessor 

The  SAE  81C99  coprocessor  was  developed  by  Siemens  Corporation.  Its  features 
include  an  8-bit  interface  to  a  microcontroller.  Peak  performance  of  this  device 
is  given  at  7 . 9  million  rules  per  second  at  a  clock  speed  of  20  MHz.  It  has  256 
inputs,  64  outputs,  and  handles  up  to  16,384  rules  (Shear  1993). 

3. 2. 2. 1.3  VY86C570  Fuzzy  Computational  Accelerator 

The  VY86C570  Fuzzy  Computational  Accelerator  (FCA)  was  developed  by  Very  Large 
Scale  Integration  (VLSI)  Technology.  It  can  execute  in  excess  of  850,000  fuzzy 
rule  evaluations  per  second  when  using  two  inputs,  one  output,  and  40  rules.  It 
is  built  around  the  Togai  InfraLogic  VY86C500  fuzzy  processor  core. 

This  device  has  a  12-bit  data  path,  256  x  12-bit  data  registers,  and  addresses 
up  to  64k  x  12  bits  of  external  rule  memory.  It  also  can  be  used  as  a  core 
design  for  custom  ICs  where  fuzzy  computational  capabilities  are  desired.  The 
VY86C570A  has  built-in  self-test  capability  (Weiss  1993). 

3. 2. 2. 1.4  NLX230  Fuzzy  Microcontroller 

The  NLX230  fuzzy  microcontroller  is  produced  by  American  NeuraLogix.  It  is 
fabricated  using  1.25-micron  CMOS  technology  and  can  execute  up  to  30  million 
rules  per  second.  The  rule  memory  is  24  bits  wide  and  can  be  programmed  with  up 
to  64  rules  which  are  shared  among  the  outputs  (Ziemacki  1993)  . 

3.3  Artificial  Intelligence  Development  Systems  and  Tools 

3.3.1  Fuzzy  Development  Systems 

Systems  developed  using  fuzzy  logic  concepts  have  used  both  conventional  CPUs  and 
special  purpose  fuzzy  logic  processors.  For  many  applications,  the  general 
purpose  CPU  will  suffice  for  the  task  at  hand.  For  most  current  fuzzy  logic 
applications,  an  8-bit  CPU  is  adequate.  In  more  demanding  applications,  the  use 
of  a  fuzzy  logic  processor  is  required  (Legg  1993). 
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For  developers  of  fuzzy  systems,  a  number  of  tools  are  available: 

■  Assembly  language  code  on  a  general  purpose  CPU 

■  Special  fuzzy  assembly  code  for  fuzzy  controllers 

■  C  code  generating  tools 

■  Complete  development  environments 

Speed  requirements  and  system  complexity  dictate  the  hardware  that  is  required. 
The  use  of  a  high  level  language,  such  as  C,  will  slow  down  the  execution  speed 
when  compared  to  a  system  developed  using  assembly-  code.  For  simpler 
applications,  fuzzy  controllers  are  not  required  and  the  system  may  be 
implemented  by  the  use  of  look-up  tables.  Where  rule  execution  speed  is  the 
primary  requirement,  high-speed  fuzzy  controllers  are  required.  Between  these 
two  extremes,  developers  use  general  purpose  CPUs  with  fuzzy  logic  software  (Legg 
1993). 

The  number  of  degrees  of  membership  (see  section  2.3)  can  be  the  determining 
factor  when  CPU  resolution  is  considered.  Complexity  of  the  system  (number  of 
rules)  is  a  determining  factor  when  speed  is  considered. 

As  with  any  digital  system  development,  tools  should  be  a  major  consideration  for 
the  choice  of  IC  used.  Tools  vary  in  capability,  price,  and  user-friendliness. 
Tools  are  used  not  only  in  the  development  phase,  but  in  the  debug  and  testing 
phases  as  well.  Some  of  the  advantages  tools  can  provide  include  (Legg  1993): 

■  Graphical  interfaces  to  simplify  editing  and  creation  of  membership 
functions 

•  Graphical  display  of  controlled  surface 

■  Tuning  of  a  system  while  it  is  active 

Tuning  a  fuzzy  system  empirically  does  not  provide  enough  assurance  of  system 
stability.  Research  is  addressing  this  issue. 

Development  environments  are  available  for  fuzzy  logic-based  systems  and  provide 
system  engineers  with  necessary  tools.  Tools  exist  for  each  level  of  debugging, 
including  data  tracing,  analysis,  and  simulation.  If  the  inference  unit  does  not 
perform  as  expected,  these  tools  can  assist  the  user  in  locating  bugs  in  the 
source  code. 

Different  target  processors  are  supported  by  a  number  of  development 
environments .  Some  development  environments  contain  a  full  compliment  of  tools 
to  take  the  design  from  inception  to  completion,  and  are  combined  into  a  single 
software  product.  These  are  referred  to  as  Integrated  Development  Environments. 

As  growth  in  this  field  continues ,  standard  fuzzy  language  code  and  portability 
among  the  various  processors  will  become  issues.  Tools  that  provide  users  with 
an  open  architecture  environment  allow  flexibility  in  their  use.  Tools  can 
provide  the  user  with  data  formats  for  membership  functions,  inference  rules, 
inference  units,  and  other  fuzzy  inference  parameters. 
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3. 3. 1.1  TILShell® 


One  development  environment  available  to  designers  is  a  graphical,  object— based 
environment  called  TILShell®.  This  shell  allows  the  user  to  define  the 
production  rules  and  membership  functions.  Three  compilers  are  provided, 
depending  on  the  choice  of  target  system.  These  compilers  allow  code  to  be 
produced  as  C  source  code,  microprocessor  specific  code,  or  machine  code  for  the 
FC110  Digital  Fuzzy  Processor  (Conner  1993)  . 

3. 3. 1.2  Fuzzy  Inference  Development  Environment 

The  Fuzzy  Inference  Development  Environment  (FIDE)  is  a  tool  based  on  Fuzzy 
Inference  Language  (FIL) .  FIL  is  a  non-sequential  language  with  English-like 
statements  that  incorporates  inference  methods  and  a  variety  of  logic  operators 
for  different  applications.  FIDE  includes  a  graphic  editor  for  describing 
membership  functions.  The  editor  converts  the  graph  into  a  segment  of  code.  The 
FIDE  compiler  translates  the  source  code  into  the  standard  data  structure. 

Debug  tools,  such  as  a  trace  facility,  graphical  analyzer,  and  simulation,  are 
also  provided.  Once  a  processor  has  been  selected  for  implementation,  the 
corresponding  real-time  code  generator  can  be  used  for  that  processor.  If  the 
unit  is  implemented  in  software,  the  run-time  library,  when  linked  into  a  C 
program,  performs  the  fuzzy  inference  computation  (Aptronix1  1992) . 

3.3.2  Fuzzy  Logic  for  Digital  Signal  Processors 

Systems  can  be  designed  using  a  fuzzy  development  package  built  around  the 
Digital  Signal  Processor  (DSP) .  This  allows  the  features  of  the  fuzzy  system 
environment  to  be  utilized  in  the  DSP  field  for  greater  flexibility  in  particular 
applications.  The  development  software  combines  fuzzy  logic  programming  and 
allows  DSP  techniques  to  be  programmed  for  the  same  hardware.  Such  a  tool  is 
available  for  the  PC  environment  (Texas  Instruments  Literature  1994) . 

3.3.3  Neural  Network  Development  Tools 

NNs  typically  are  not  standalone  devices.  They  generally  are  used  as  part  of  a 
larger  system.  A  process  passes  data  to  the  NN  inputs.  The  NN  then  performs  its 
operation  and  passes  the  output  data  back  to  the  process.  This  is  true  for  both 
software—  and  hardware-based  NNs. 

Designers  need  to  keep  in  mind  some  potential  drawbacks  when  using  NNs. 

There  may  not  exist  a  satisfactory  solution  for  a  given  problem  if  data  are 
insufficient  or  if  there  is  no  learnable  function.  The  problem  must  be 
definable.  Training  data  need  to  be  available  and  sufficient  for  the  defined 
problem. 

Proving  consistency,  completeness,  and  correctness  for  an  NN  may  be  difficult. 
The  outputs  of  NNs  depend  on  a  high  number  of  calculations .  These  calculations 
are  based  on  input  patterns  and  weights.  The  origin  of  the  weights  may  be 
difficult  to  explain,  since  they  are  the  result  of  a  complex  machine  learning 
procedure . 
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NNs  can  be  expensive  to  train.  The  training  expense  is  due  to  the  need  to 
collect,  study,  and  exercise  the  data.  Additionally,  the  developer  will  need  to 
manipulate  parameters  until  the  NN  response  is  acceptable. 

For  NNs  implemented  using  microprocessors,  small  increases  in  the  number  of  nodes 
required  cause  large  increases  in  execution  time.  As  a  rule  of  thumb,  the 
execution  time  is  roughly  the  square  of  the  number  of  nodes.  A  microprocessor 
that  works  for  a  small  number  of  nodes  may  not  meet  the  required  response  time 
where  the  number  of  nodes  is  larger  (Hammerstrom  1993)  . 

Developers  of  NNs  have  the  option  of  using  a  software-implemented  NN  or  an  NN 
hardware  IC.  Hardware  devices  are  a  relatively  recent  development  and  are 
generally  expensive.  However,  if  a  software  solution  is  too  slow,  a  hardware  NN 
may  be  required. 

NN  developers  need  to  weigh  the  characteristics,  requirements,  and  drawbacks  of 
this  technology  carefully.  Computational  needs  should  be  considered,  including 
system  throughput  and  the  availability  of  training  data.  Sufficient  data  must 
be  available  to  give  a  good  representation  of  the  behavior  to  be  modeled. 

If  NNs  are  to  be  used  in  critical  applications,  other  factors  need  to  be 
considered.  Hammerstrom  (1993)  sums  up  the  design  concerns  effectively  when  he 
states : 

They  are  like  statistics  in  their  aggregate  behavior,  their 
usefulness,  and  their  effectiveness  in  applications  that  lack  other 
solutions  and  tolerate  imprecision.  They  may  be  unsuitable  when 
safety  is  critical  or  risks  are  to  be  avoided,  unless  they  can  be 
validated  with  all  possible  input  values. 

A  number  of  manufacturers  are  marketing  tools  to  assist  in  the  design  of  NNs. 
NN  development  tools  support  software  driven  NNs  and  hardware  NNs.  Based  on  the 
design  considerations,  the  developer  chooses  one  of  the  two  methods.  Tools  run 
on  various  systems,  including  DOS,  Macintosh,  Unix,  VMS,  and  OS/2.  Hammerstrom 
(1993)  lists  a  variety  of  currently  available  development  tools  for  both  software- 
and  hardware— based  NN  design. 

3.3.4  Neural  Network  and  Fuzzy  Logic  Combined  System 

An  NN  and  fuzzy  logic  system  have  been  combined  in  a  product  called  NeuFuz4 , 
which  generates  code  for  the  C0P8  /iC  (Shear  1993).  The  development  package  uses 
an  NN  to  assist  in  building  fuzzy  logic  applications,  since  generating  membership 
functions  and  fuzzy  rules  can  be  difficult. 

Input  and  output  data  and  other  application  parameters  are  used  to  create  the 
fuzzy  logic  rules  and  membership  sets.  NN  weights  are  adjusted  until  the  outputs 
of  the  network  closely  match  the  outputs  of  the  training  set,  given  the  same  set 
of  inputs.  The  final  weights  represent  behavior  that  can  be  translated  into 
rules  and  membership  functions  (Legg  1993).  The  rules  are  then  examined  by  a 
rule  verifier  and  processed  by  an  optimizer.  When  the  developer  is  satisfied 
with  the  system  simulation,  machine  code  for  the  host  processor  can  be  generated. 
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The  NeuFuz4  neural  tool  uses  supervised  learning.  Also  under  development  is  a 
similar  tool  that  uses  unsupervised  learning.  It  is  anticipated  that  NN 
development  tools  used  in  training  the  fuzzy  system  will  migrate  into  the  fuzzy 
controller  (Legg  1993)  . 
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4.  ARTIFICIAL  INTELLIGENCE  AND  EXPERT  SYSTEM  APPLICATIONS 


Much  research  has  been  performed  in  the  field  of  AI .  Numerous  studies  have  been 
funded  or  performed  by  government  laboratories  and  agencies,  as  well  as  private 
industry  and  universities.  This  section  examines  some  of  the  aviation-related 
studies,  particularly  systems  proposed  for  airborne  application.  Al-based 
aircraft  monitoring  and  diagnostic  systems  are  also  examined.  This  section  will 
identify  some  of  the  design  considerations  for  such  applications. 

4.1  Design  Considerations  for  Avionic  Applications 

Designers  of  ESs  must  answer  many  questions  during  the  course  of  development. 
These  questions  consider  high  level  issues,  such  as  system  requirements,  and 
black  box  issues,  such  as  the  type  of  system,  inputs,  processes,  outputs,  and 
interfaces.  Many  minute  details  must  also  be  examined  to  implement  the  system. 

4.1.1  Architecture  Considerations 

Avionic  subsystems  for  advanced  military  aircraft  will  provide  a  host  of  complex 
functionality.  The  high  number  of  sensors  on  modern  aircraft  requires  that  data 
management  be  given  careful  consideration.  Assimilation  of  the  wealth  of  data 
available  presents  a  difficult  task  for  any  crew.  Information  needs  to  be 
compressed  and  sorted,  presenting  meaningful  and  necessary  results  to  the  crew. 
This  function  will  be  computationally  intensive,  requiring  reliable  and  high- 
throughput  processing.  Al-based  systems  are  targeted  to  help  reduce  the  amount 
of  information  requiring  the  pilot's  attention. 

When  designing  an  ES ,  one  must  choose  an  architecture  consistent  with  the 
requirements.  The  influence  of  timing  considerations  on  the  architecture  and 
hardware  selected  for  the  development  task  will  need  to  be  determined.  The 
system  timing  requirements  and  architecture  choice  influence  the  implementation. 
Designers  are  faced  with  many  decisions,  including  whether  to  choose  a  single  CPU 
or  a  multi-processor  configuration;  conventional,  RISC,  or  special  purpose  CPUs; 
message  passing  schemes;  memory  design;  operating  system;  and  numerous  other 
related  issues. 

4.1.2  Timing  Considerations 

Timing  is  another  example  of  a  necessary,  but  important,  detail  when  designing 
an  ES  for  quick  response  or  real-time  operation.  Following  are  some  of  the 
timing  issues  designers  need  to  be  aware  of,  or  implement  in  their  ESs,  according 
to  Ng  (1988) : 

■  Demonstrating  that  under  any  given  scenario  the  system  will  provide  data 
when  desired,  in  a  timely  manner. 

■  Addressing  response  latency.  Algorithms,  such  as  those  that  perform  LISP 
garbage  collection,  should  be  formulated  with  a  time-sliced  version  to 
reduce  response  latency. 
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■  Bounding  problems  so  that  the  best  reasonable  solution  under  the 
circumstances  can  be  identified. 

■  Eliminating  unnecessary  overhead  from  interactive  development 

environments . 

•  Matching  the  processor  architecture  to  the  High-Level  Language. 

■  Where  higher  speeds  are  required,  using  parallel  algorithms,  RISC 
processors,  or  other  special  hardware. 

4.2  Flight  Management  Expert  System 

As  aircraft  systems  become  increasingly  complex,  the  pilot's  mental  and  physical 
workload  will  increase  beyond  realistic  limits.  Expert  flight  management  systems 
can  assist  decision-making  processes  for  the  pilot.  However,  problems  can  arise 
in  acquiring,  structuring,  and  applying  the  knowledge  base  needed  by  an  expert 
flight  management  system  capable  of  operating  in  a  dynamic  domain. 

The  Emergency  Procedures  Expert  System  (EPES)  is  a  decision  aid  system  suited  for 
flight  management  applications.  The  goal  of  the  system  is  to  provide  pilot 
assistance  during  emergency  situations  while  keeping  the  pilot  in  the  loop. 
During  normal  operations,  the  EPES  would  remain  unseen  to  the  pilot,  but  would 
monitor  the  state  of  the  aircraft  constantly.  If  an  emergency  were  to  arise,  the 
EPES  would  initiate  steps  to  correct  the  emergency,  inform  the  pilot  of  the 
action,  and  allow  the  pilot  to  override  the  action,  if  desired. 

The  EPES  is  comprised  of  an  environmental  simulation  and  an  ES .  The 
environmental  simulation  models  the  behavior  of  the  aircraft  and  provides  a 
display  panel  with  realistic  dials  and  gauges.  The  ES  contains  a  special  purpose 
inference  engine  and  the  knowledge  base . 

A  rule/goal  paradigm  for  managing  emergencies  forms  the  basis  for  the  knowledge 
base.  Data-driven,  condition-action  rules  are  triggered  by  changes  in  the  state 
of  the  knowledge  base.  Corrective  actions  are  defined  by  goals  that  become 
active  when  one  or  more  emergencies  arise. 

The  EPES  is  intended  to  represent  the  knowledge  of  an  experienced  pilot  in 
handling  multiple  emergencies.  A  top-down  approach  to  knowledge  acquisition  was 
used  in  the  development  process.  The  knowledge  base  was  developed  incrementally 
over  time  at  increasing  levels  of  detail.  The  knowledge  base  was  developed  as 
a  collaboration  between  the  knowledge  engineer  and  pilot.  The  knowledge  engineer 
gathered  basic  emergency  information  from  the  flight  manual.  However,  to  create 
a  system  that  performed  at  an  expert  level,  the  knowledge  of  an  experienced  pilot 
was  needed. 

During  knowledge  base  development  for  EPES,  a  number  of  lessons  were  learned: 

■  Although  emergency  procedures  were  described  separately ,  often  they  were 

interrelated. 
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■  Rules  and  goals  were  developed  more  effectively  in  parallel  and  in  an 
iterative  cycle. 

■  The  structured  text  representational  format  allowed  the  knowledge  engineer 
to  isolate  portions  of  the  knowledge  base  that  were  incomplete.  Specific 
questions  could  be  generated  to  obtain  the  missing  knowledge  and  to 
minimize  interview  time. 

■  Simulation  exercises  facilitated  pilot  feedback  and  aided  in  capturing 
knowledge  that  otherwise  would  have  been  difficult  to  obtain. 

Although  these  processes  were  used  in  a  flight  management  domain,  this  approach 
to  knowledge  base  development  could  be  applicable  to  similar  domains  with  dynamic 
environments  (Anderson,  et  al .  1985). 

4.3  Navigation  Systems 

The  Knowledge-Based  AutoPilot  (KBAP)  is  a  NASA/RAE  cooperative  program 
established  to  develop  and  validate  a  real-time  KBAP.  The  program  investigates 
implementation  and  validation  issues.  The  KBAP  "provides  a  simple  well  defined 
yet  real  problem  within  which  to  explore,  develop,  and  demonstrate  real-time 
knowledge-based  system  concepts  and  validation  and  verification  techniques  for 
mission-critical  systems”  (Daysh,  et  al .  1991). 

A  prototype  autopilot  was  developed  using  CLIPS,  but  was  found  to  be  too  slow  for 
real-time  flight  control  applications:  The  RAE  developed  FLEX  (a  library  of 

FORTRAN  77  subroutines  that  allow  FORTRAN  programs  to  interface  with  ESs)  and  has 
applied  it  to  this  application  with  much  improved  response  time.  One  of  the 
immediate  goals  for  improving  the  response  time  is  to  use  the  rules  produced 
under  CLIPS  and  implement  them  under  FLEX.  The  long-term  goal  is  to  apply  the 
conventional  software  verification  and  validation  (V&V)  methodology  used  for 
flight  critical  control  systems  to  the  KBAP  (Daysh,  et  al .  1991). 

4.4  Decision  Support  Systems 

Curran  (1992)  states  that  Al  will  likely  be  employed  in  the  future  to  monitor  and 
assist  the  pilot.  Some  of  the  proposed  decision  support  systems  are  examined  in 
this  section. 

4.4.1  Cockpit  Assistant  System 

The  CASSY  is  a  knowledge-based  computer  aid  for  flight-planning  tasks.  The 
purpose  of  this  system  is  to  support  the  pilot  in  complex  planning  and  decision 
operations  during  situation  assessment  and  flight  replanning  operations.  This 
system  has  been  implemented  in  flight  simulators  for  single  pilot  and  dual  pilot 
testing.  Research  is  being  conducted  by  Dornier  and  the  University  of  the  German 
Armed  Forces  in  Munich. 

Many  accidents  in  highly  automated  cockpits  have  been  attributed  to  human  error. 
The  intent  of  CASSY  is  to  use  Al  to  reduce  the  number  of  accidents  attributed  to 
human  error.  CASSY  functions  like  an  expert  copilot  to  recommend  flight  plan 


20-59 


revisions,  to  provide  warning  if  the  pilot  deviates  from  ATC  clearances,  and  to 
monitor  aircraft  systems. 

CASSY  monitors  the  aircraft  systems  to  supply  the  air  crew  with  warnings  and 
advice.  It  performs  situation  assessment  and  planning  activities  using  a 
knowledge  base  of  ATC  rules,  airways,  instrument  approaches,  and  instrument 
procedures.  CASSY  uses  voice  recognition  technology  to  communicate  with  the 
pilot  and  data  link  to  communicate  with  ATC.  Future  plans  include  providing  ATC 
clearances  directly  to  the  pilot  and  CASSY  via  data  link. 

When  a  pilot  deviates  from  the  approved  flight  plan,  CASSY  infers  whether  the 
deviation  was  intentional  or  accidental.  The  pilot  is  given  verbal  advice  when 
a  deviation  is  beyond  the  prescribed  tolerance. 

The  results  of  simulator  tests  have  been  encouraging.  It  is  the  intent  of  CASSY 
to  simplify  the  decision-making  process,  yet  keep  the  pilot  in  the  decision  loop. 
During  simulator  trials,  pilots  using  CASSY  responded  to  ATC  warnings  within  5 
seconds.  Pilots  without  the  system  took  from  15  to  95  seconds  to  evaluate  the 
situation  and  respond. 

System  tests  have  been  ongoing  and  future  tests  will  be  performed  on  aircraft. 
CASSY  could  be  operational  within  10  years  (Nordwall  1992  and  Prevot,  Onken,  and 
Dudek  1991) . 

4.4.2  Diverter  System 

The  Diverter  System  is  an  AI  application  that  provides  pilots  with  information 
for  making  in-flight  diversion  decisions.  In  August  1990,  a  report  describing 
the  prototype  system  was  prepared  for  NASA.  The  goal  of  the  Diverter  System  is 
to  use  AI  and  algorithm— based  decision  aiding  to  replicate  a  pilot's  information 
processing  and  application  of  logic  principles  during  in-flight  diversion 
planning.  The  Diverter  System  is  designed  to  resemble  closely  the  cognitive  and 
information  processing  functions  used  by  pilots  during  diversion  functions. 

The  Diverter  System  is  designed  to  be  "invisible,"  although  continuously  active, 
until  a  situation  arises  that  requires  planning,  display,  and  execution  of  a 
diversion.  Background  activity  consists  of  constant  database  updates  from 
onboard  systems,  as  well  as  from  ground-based  systems  through  data  link 
communications.  Data  are  not  displayed  unless  the  system  is  activated. 

Activation  is  accomplished  either  by  the  pilot  or  by  the  Diverter  System.  A  menu 
option  of  the  flight  data  Control  Display  Unit  (CDU)  allows  the  pilot  to  activate 
the  Diverter  System.  Automatic  activation  occurs  when  the  reason  for  diversion 
is  due  to  a  change  in  onboard  aircraft  system  status  or  information  from  data 
link  communications  from  ground-based  sources.  Activation  annunciation  takes 
place  through  the  aircraft's  fault/system  status  annunciation  system. 

A  functional  flow  analysis  was  developed  by  querying  pilots  (domain  experts)  to 
obtain  the  methods  and  logic  used  during  diversion  planning.  This  information 
was  augmented  with  information  from  sources  such  as  Federal  Aviation  Regulations 
(FARs)  and  the  Airmen's  Information  Manual  (AIM). 
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The  Diverter  prototype  is  capable  of  combining  available  knowledge  and  using 
built-in  knowledge  to  determine  the  best  combination  of  runway,  airfield,  and 
route.  The  resultant  route  is  then  suggested  to  the  pilot.  In  an  actual  system, 
runway,  airfield,  and  aircraft  attributes  would  be  stored  onboard,  while 
information,  such  as  weather  and  navigation  aid  status,  would  be  obtained  through 
data  link  or  pilot  input.  The  current  Diverter  System  prototype  did  not  attempt 
to  define  how  this  information  transfer  would  take  place.  Also,  the  form  in 
which  information  would  be  presented  was  not  defined. 

4.4.3  Flight-Plan  Interactive  Negotiation  and  Decision-Aiding  System 

The  Flight-Plan  Interactive  Negotiation  and  Decision-Aiding  System  for  Enroute 
Rerouting  (FINDER)  is  being  developed  by  Sextant  Avionics  and  will  be  tested  by 
Air  France  pilots  when  completed.  FINDER  is  an  interactive  system  that  uses  ES 
techniques,  as  well  as  conventional  code  written  in  C  and  C++. 

FINDER'S  purpose  is  to  suggest  a  limited  number  of  satisfactory  solutions  for 
crew  members  facing  a  diversion  situation  (FINDER  1)  or,  more  generally,  an 
enroute  replanning  situation  (FINDER  2)  .  The  system  focuses  on  managing  existing 
data  and  making  decisions  that  aid  the  pilot.  Following  is  information  that 
FINDER  will  use  to  provide  pilot  assistance  (Bittermann,  et  al.  1994): 

•  Fuel  capacity 

■  Weather  forecasts 

■  Ground  facilities 

■  Regulations 

*  Passenger— based  constraints 

The  problem  is  clearly  stated  here  (Bittermann,  et  al .  1992): 

...when  pilots  are  confronted  with  diversion  situations,  they  must 
find  a  solution  which  theoretically  integrates  all  the  parameters 
within  a  limited  time  and  is  based  solely  on  their  personal 
experience.  Their  attention  is  mainly  concentrated  on  the  critical 
considerations  that  may  affect  the  aircraft's  survival  (fuel, 
weather) . 

The  system  will  also,  upon  request,  give  reasons  for  a  particular  selection  and 
allow  modification  by  pilot/system  dialog. 

It  is  assumed  that  FINDER  will  have  data  link  connections  available  with  the 
airline  owner,  ATC,  and  possible  destination  airports.  In  addition,  information 
is  necessary  from  the  Central  Maintenance  System  and  the  Electronic  Library 
System.  FINDER  will  also  investigate  the  impact  of  the  evolving  negotiation 
process  between  the  crew  and  ATC. 

A  diversion  is  generated  by  FINDER  using  a  two-phase  decision  process.  Figure 
4.4-1  shows  how  the  process  works. 

The  first  phase,  Context  Analysis,  examines  the  environment  as  completely  as 
possible.  This  includes  the  condition  of  the  aircraft  and  facts  about  the 
possible  destination  airports. 
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FIGURE  4.4-1.  DIVERSION  PROPOSAL  GENERATION 
(Bittermann,  et  al.  1992) 


The  second  phase,  Diversion  Proposal,  starts  with  the  type  of  action  determined 
by  the  Context  Analysis  phase  and  seeks  to  arrive  at  a  satisfactory  solution  in 
light  of  all  known  facts.  The  first  stage  of  the  Diversion  Proposal  selects  a 
number  of  possible  destination  airports,  based  on  the  destination  analysis 
information  for  those  airports.  Using  optimization  heuristics,  the  optimum  route 
is  selected  for  the  possible  destination  airports. 

The  last  stage  of  this  phase  is  the  destination  airport  proposal  and  dialog  with 
the  pilot.  A  Graphical  User  Interface  (GUI)  is  used  for  the  pilot— system 
interface.  A  list  of  proposed  airports  is  displayed  by  the  GUI.  If  the  pilot 
selects  one  of  the  proposed  airports,  the  system  will  handle  the  necessary 
interface  with  ATC  via  the  data  link. 

If  the  pilot  does  not  select  one  of  the  airports,  he  or  she  can  modify  the 
parameters  used  in  decision  making.  This  will  cause  the  system  to  regenerate  the 
list  of  proposed  airports  in  light  of  these  new  parameters.  This  new  list  will 
then  be  displayed  for  selection  or  further  modification  by  the  pilot. 

The  concept  of  diversion  assistance  during  the  FINDER  1  project  led  to  the  FINDER 
2  project.  FINDER  2  is  devoted  to  developing  an  enhanced  real-time  demonstrator 
with  extended  replanning  features  (avoidance  and  optimization)  and  an  enriched 
simulation  environment  (weather  events,  predictions  and  reports,  regulated  areas, 
and  ATC  and  operation  constraints) . 
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The  situation  assessment  module  has  been  extended  to  overall  environment  and 
aircraft  monitoring.  It  identifies  potential  problems,  proposes  corrective 
actions,  and  provides  the  crew  with  a  comprehensive  picture  of  the  context 
evolution. 

Each  solution  generated  is  maintained  in  association  with  the  context  and 
aircraft  evolution  (i.e.,  if  an  unaccessible  airport  becomes  available  while  in 
diversion  mode,  the  previously  proposed  solutions  are  automatically  updated) . 

The  pilot-system  interface  is  hosted  by  an  enhanced  Electronic  Library  System 
Pilot  Access  Terminal.  The  logic  of  the  dialog  has  been  defined  according  to 
cognitive  modelling  procedures.  The  software  architecture  takes  advantage  of 
concurrency  between  the  modules  of  the  system's  kernel  (mainly  situation 
assessment,  replanning,  and  dialog).  Human— like  explanations  are  continually 
provided  by  the  system  on  the  pilot's  request. 

4.4.4  Pilot's  Associate  Program 

A  significant  amount  of  aviation-related  AI  research  in  recent  years  has 
originated  from  programs  funded  by  the  U.S.  Air  Force  (USAF)  Aeronautical  Systems 
Division.  One  such  program,  Pave  Pace,  will  investigate  and  validate  many  areas 
of  new  technology,  including  AI  algorithms,  to  assist  in  mission  decision  making 
and  NN  parallel-processing  capability  for  adaptive  learning  systems  (Curran 
1992). 

The  USAF  and  the  ARPA  awarded  a  contract  to  a  team  from  Lockheed  and  a  team  from 
McDonnell  Douglas  Corporation.  This  program,  the  Pilot's  Associate  (PA),  has  the 
goals  of  defining,  designing,  and  demonstrating  the  application  of  machine 
intelligence  to  the  assistance  of  advanced  fighter  aircraft  pilots  (Leavitt  and 
Smith  1989).  The  Lockheed  team  was  awarded  a  contract  to  develop  an  ES  that 
tailored  its  response  to  the  pilot's  particular  style  of  flying. 

This  particular  system  had  technically  difficult  constraints .  It  had  to  react 
to  inputs  and  communicate  with  the  pilot  rapidly.  In  addition,  the  knowledge 
base  was  designed  to  receive  inputs  from  a  variety  of  systems.  The  construction 
of  the  knowledge  base  relied  on  inputs  from  human  factors  experts,  psychologists, 
engineers,  and  pilots. 

One  goal  of  the  PA  program  is  to  have  all  of  the  software  running  on  an  avionic 
processor  using  a  real-time  procedural  language,  such  as  C  or  Ada  (Rouse,  Geddes , 
and  Hammer  1990)  . 

4.4.5  Rotorcraft  Pilot's  Associate  Program 

The  Rotorcraft  Pilot's  Associate  (RPA) ,  a  program  sponsored  by  the  U.S.  Army,  has 
similar  goals  to  the  PA  program.  The  Army  requested  proposals  from  industry  to 
develop  a  system  that  would  alleviate  the  workload  of  rotorcraft  combat  pilots. 
The  RPA  proposes  the  use  of  a  knowledge-based  system  to  draw  upon  the  knowledge 
of  experts  with  prior  experience  in  this  discipline. 

During  the  Vietnam  era,  a  number  of  lessons  were  learned  about  combat  avionics. 
It  was  found  that  when  fighter  aircraft  and  rotorcraft  approached  a  combat  zone, 
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pilots  were  shutting  down  some  systems.  The  systems  remaining  "on"  were  those 
that  worked  automatically  and  reliably,  yet  kept  the  pilot  fully  aware  of  system 
status.  These  systems  were  advisory  in  nature  and  the  pilot  always  was  in 
command  of  the  system. 

The  RPA  program  follows  this  design  trend.  The  system  monitors  the  rotorcraft 
and  provides  situation  awareness.  If  an  unknown  target  is  encountered,  the 
system  suggests  the  correct  response.  The  pilot  can  choose  to  accept  the 
response  or  reject  it.  If  the  response  is  accepted,  the  system  implements  it 
automatically.  The  purpose  of  this  system  is  to  reduce  cockpit  workload  and  free 
the  pilot  to  concentrate  on  tasks  necessary  for  combat  survival.  Figure  4.4-2 
identifies  the  basic  functions  included  in  the  RPA. 


Advanced  MEP 


The  knowledge  base  will  require  detailed  study  and  definition  of  the  decisions 
that  a  pilot  must  make  in  combat  aviation.  In  addition,  difficult  issues ,  such 
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as  deciding  which  functions  to  automate  and  which  are  best  left  to  the  pilot, 
will  need  to  be  faced.  The  growth  of  AI  technology  makes  the  RPA  project  viable 
for  future  combat  rotorcraft  (Harvey  1993) . 

4.5  Intelligent  Monitoring  and  Diagnostic  Systems 

As  aircraft  systems  become  more  complex,  difficulties  have  increased  for  system 
maintenance  tasks.  False  alarms  consume  as  much  as  50  percent  of  maintenance 
resources,  while  troubleshooting  actions  take  as  much  as  50  percent  of  total 
labor  hours  spent  for  repair.  Accurate  and  efficient  diagnostic  systems  are 
needed. 

Developing  rule  bases  for  complex  system  diagnostics  is  difficult.  Few  experts 
possess  ample  understanding  of  new  systems  to  provide  adequate  diagnostic  rules. 
If  multiple  experts  are  used,  it  is  difficult  to  gain  consensus  about  the  rules. 
These  problems  may  be  addressed  by  using  rules  based  on  causal  relationships 
between  failures  and  test  information  and  by  developing  rules  from  examples  of 
actual  or  simulated  failures.  However,  providing  sufficient  examples  to  produce 
adequate  fault  trees  may  be  impractical. 

ESs  are  being  developed  for  a  number  of  aspects  of  avionics  diagnostic  testing. 
ESs  monitor  the  results  of  Built-In  Test  (BIT)  applications  to  provide  better 
localization  capability.  Performance  monitoring  and  fault  locating  software 
determine  the  cause  of  anomalies  as  they  occur.  In  the  future,  software  will  be 
integrated  into  onboard  maintenance  systems  to  allow  online  diagnosis, 
reconfiguration,  and  repair. 

Another  application  of  ESs  is  production  of  Interactive  Electronic  Technical 
Manuals  (IETMs)  and  Portable  Maintenance  Aids  (PMAs) .  IETMs  and  PMAs  combine 
online  technical  information  with  maintenance  facilities. 

ESs  are  beginning  to  be  used  in  avionics  testing  as  test  executives  for 
intelligent  Automatic  Test  Equipment  (ATE).  The  ATE  systems'  capabilities  are 
as  follows: 

■  Learn  from  experience 

■  Devise  and  execute  test  strategies  dynamically 

■  Correct  errors 

■  Explain  and  validate  test  choices 

4.5.1  Rotorcraft  Transmission  Health  Monitoring  System 

As  commercial  and  military  aircraft  age,  there  is  increased  emphasis  on 
maintenance  and  safety  issues.  One  important  problem  in  this  area  is  predicting 
impending  faults  in  helicopter  transmissions.  In  new  aircraft,  advanced 
diagnostics  in  which  continuously  monitored  volumes  of  data  must  be  reduced  to 
provide  meaningful  information  to  pilots  or  ground  crews  also  are  important. 

The  Office  of  Naval  Research  (ONR)  has  initiated  an  aircraft  health  monitoring 
program  that  is  investigating  the  use  of  NNs  in  mechanical  diagnostic  systems. 
Reduced  complexity,  speed,  and  cost  were  cited  as  advantages  of  using  NNs  in 
diagnostic  systems.  Reduced  complexity  would  increase  the  reliability  of  a 
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diagnostic  system.  NNs  will  allow  real-time  diagnostics  to  be  performed  onboard 
the  aircraft.  These  diagnostics  will  fuse  data  from  the  power  train,  drive 
train,  structure,  rotor  system,  and  oil  systems.  As  ICs  to  support  this 
technology  become  mass  produced,  the  cost  of  this  technology  will  be  increasingly 
affordable . 


In  June  1992,  ONR  contractors  began  work  on  an  NN  application  to  detect 
helicopter  gearbox  faults.  Phase  1  has  concentrated  on  detection  and  feature 
extraction.  Subsequent  phases  of  the  ONR  program  will  focus  on  classification, 
network  design,  and  potential  migration  to  a  commercial  product. 

Preliminary  ONR  reports  indicate  a  need  for  more  and  higher  quality  data  with 
both  fault  and  normal  conditions.  In  the  future,  implementation  of  a  data  fusion 
approach  for  health  monitoring  will  involve  ESs,  blackboards,  NNs,  and  other  AI 
technologies.  Research  still  is  needed  in  areas  such  as  smart  sensors,  improved 
system-state  recording,  advanced  algorithms,  and  faster  data  sampling  and 
processing.  Programs  such  as  the  ONR  research  in  transmission  diagnosis  can 
enhance  safety  by  using  AI  to  improve  health  and  usage  monitoring  (Rock,  Malkoff , 
and  Stewart  1993) . 

4.5.2  Technical  Expert  Aircraft  Maintenance  System 

The  complexity  of  modern  combat  aircraft  avionic  systems  makes  diagnosis  and 
repair  of  these  systems  a  difficult  process.  Knowledge  of  the  aircraft,  as  well 
as  a  broad  base  of  repair  experience,  is  needed.  Faults  that  occur  during 
initial  testing  of  newly  manufactured  aircraft  are  especially  difficult  to 
isolate,  since  the  assumption  that  a  failed  system  once  worked  correctly  cannot 
be  made*.  Typically,  after  each  test  flight,  a  team  of  mechanics  fixes  any 
problems  that  were  discovered.  The  team  of  mechanics  is  supported  by  a  staff  of 
engineers  who  are  specialists  for  each  specific  system. 

The  Technical  Expert  Aircraft  Maintenance  System  (TEAMS) ,  developed  by  McDonnell 
Aircraft  Company,  is  an  interactive  ES  that  supports  problem  diagnosis  in  new 
aircraft.  Using  an  ES  in  fault  diagnosis  supports  the  mechanic's  diagnostic 
decision-making  process  and  reduces  the  need  for  engineering  support. 

Development  of  ES  technology  applied  to  maintenance  systems  occurred  in  several 
stages.  The  first  stage  involved  an  evaluation  of  the  technology  and  its 
expected  impact  on  the  aircraft  delivery  process.  An  ES  was  developed  for  the 
Communication,  Navigation,  and  Identification  (CNI)  suite  of  systems.  During  a 
3— month  study  period  designed  to  assess  the  impact  of  the  ES ,  it  was  determined 
that  the  CNI  ES  could  result  in  a  significant  reduction  in  diagnostic  time.  The 
study  also  showed  a  reduction  in  the  number  of  test  flights  required  to  sell  an 
aircraft  and  a  reduction  in  the  number  of  spares  required  to  be  kept  in 
inventory . 

Quiuxig  stage  2,  additional  ESs  were  developed  based  on  the  results  of  stage  1. 
Flight  controls  and  radar  were  selected  for  stage  2  because  they  produce  the 
greatest  number  of  flight  faults  in  the  avionic  systems  and  isolation  of  failures 
in  these  systems  requires  considerable  engineering  support.  This  ES  was 
developed  using  CLIPS.  Stage  3  involved  expanding  the  ES  concept  to  other 
programs . 
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During  stage  2,  additional  ESs  were  developed  based  on  the  results  of  stage  1. 
Flight  controls  and  radar  were  selected  for  stage  2  because  they  produce  the 
greatest  number  of  flight  faults  in  the  avionic  systems  and  isolation  of  failures 
in  these  systems  requires  considerable  engineering  support.  This  ES  was 
developed  using  CLIPS.  Stage  3  involved  expanding  the  ES  concept  to  other 
programs . 

A  number  of  approaches  were  used  to  involve  the  end  user  in  the  project  and  to 
encourage  user  acceptance  of  TEAMS.  A  training  course  was  developed  as  soon  as 
the  CNI  system  was  complete.  The  course  focused  on  basic  operation  of  the  system 
and  using  the  system  in  a  simulated  environment  to  find  flight  faults.  A  comment 
feature  was  added  to  TEAMS.  This  feature  allowed  users  to  enter  a  remark  at  any 
time  during  their  use  of  the  ES .  The  comment  feature  provided  a  valuable  source 
of  feedback.  When  comments  were  made,  the  designers  were  contacted  for 
clarification  (Lischke  and  Meyer  1992) . 
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5.  CERTIFICATION  CONSIDERATIONS  FOR  ARTIFICIAL  INTELLIGENCE 


Depending  on  the  intended  use  of  a  software-based  system,  incorrect  software  can 
result  in  significant  safety  or  economic  impacts.  When  safety  issues  are  a 
primary  consideration,  a  software-based  system  may  be  required  to  undergo 
certification  corresponding  to  its  application  and  criticality.  Critical 
applications  of  software  require  rigorous  attention  to  methods  for  reducing  the 
probability  of  failure  and  ensuring  the  safety  of  those  potentially  affected  by 
the  failure  of  such  software.  This  is  no  less  true  when  applied  to  Al-based 
software.  A  "bug"  in  the  Al-based  software  in  a  research  lab  may  have  minimal 
effects.  However,  a  bug  in  the  ES  used  to  control  stock  market  buying  and 
selling  or  in  the  ES  used  to  diagnose  and  monitor  nuclear  power  generation 
systems  may  have  far-reaching  consequences. 

For  airborne  software,  certification  is  the  process  of  obtaining  FAA  approval  for 
the  design,  manufacture,  and/or  sale  of  a  part,  subsystem,  system,  or  aircraft 
by  establishing  that  it  complies  with  applicable  government  regulations.  The 
purpose  of  certification  is  to  demonstrate  and  record  that  the  total  aircraft  is 
suitable  and  safe  for  use  (Elwell,  et  al .  1991).  Key  to  certification  is  proving 
the  software  to  be  reliable  and  high  in  quality  by  a  thorough  examination  of  the 
methods  used  in  designing,  coding,  testing,  and  life  cycle  planning. 

Much  research  has  taken  place  related  to  verification,  validation,  and  testing 
of  Al-based  ES s.  This  section  presents  some  of  the  methods  and  considerations 
relating  to  this  discipline  for  Al-based  software.  A  background  of  V&V 
techniques  for  conventional  software  is  provided.  Additionally,  this  section 
highlights  some  of  the  concerns  relating  to  the  proposed  use  of  AI  technology  in 
the  cockpit. 

5.1  Certification  and  Federal  Aviation  Regulations 

When  a  major  design  effort  is  required  to  develop  a  system,  the  integrity  of  the 
aircraft  into  which  it  will  be  installed  is  in  question.  Thus,  one  of  two  type 
certification  processes  must  be  followed  to  receive  a  certificate.  For  totally 
new  designs,  or  changes  that  are  so  extensive  as  to  require  a  complete 
reinvestigation  of  the  design,  the  developer  must  follow  the  process  required  to 
obtain  a  Type  Certificate  (TC)  for  the  aircraft.  For  major  changes  (as  defined 
in  FAR  Part  21,  section  93)  to  a  system  previously  approved  under  a  TC ,  the 
developer  can  follow  a  simpler  process  to  obtain  a  Supplemental  Type  Certificate 
(STC) . 

The  Technical  Standing  Order  (TSO)  authorization  method  of  approving  components 
was  developed  to  allow  manufacturers  to  substitute  equivalent  components  "off- 
the-shelf"  without  jeopardizing  the  existing  TC.  Since  a  TSO  authorization 
request  must  be  processed  within  30  days  and  does  not  require  integration 
testing,  manufacturers  use  this  method  rather  than  Type  Certification  whenever 
possible . 
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In  the  days  of  simpler  aircraft  design,  TSO  authorizations  were  adequate.  Now, 
however,  digital  avionic  systems  are  more  complex  and  require  elaborate  testing 
procedures.  To  improve  the  TSO  approval  process,  Aircraft  Certification  Offices 
(ACOs)  are  becoming  more  involved  in  approving  new  digital  systems.  They  are 
reviewing  V&V  plans  for  TSO  packages  and  are  working  more  closely  with  the 
manufacturers.  The  ACOs  are  suggesting  that  system  integration  test  plans  be 
required  for  substitutions  in  integrated  digital  systems. 

As  avionic  systems  become  more  complex,  the  manufacturer  must  ensure  that  the 
system  will  function  as  intended  within  its  operating  environment. 
Manufacturers'  validation  facilities  will  play  a  major  role  in  establishing  the 
requirements  for  integration  testing,  since  the  functions  of  digital  avionic 
systems  will  be  simulated  there.  The  certification  requirements  will  expand  for 
such  systems  to  reflect  the  FAA's  concern  that  the  systems  safely  perform  their 
functions  once  they  are  installed  in  an  aircraft. 

The  system  to  be  certificated  can  be  simple  or  complex.  The  FARs  stipulate  which 
process  must  be  followed  in  each  case.  Although  the  manufacturer  may  refer  to 
the  FARs  to  decide  which  approval  should  be  sought,  often  a  Certification 
Engineer  (CE)  recommends  which  application  the  manufacturer  should  submit.  The 
authority  for  determining  whether  a  change  constitutes  a  modification  or  a 
redesign,  and  whether  a  redesign  is  minor  or  major,  rests  with  the  ACO. 

5.2  Certification  Guidelines 

In  general,  to  show  compliance  with  the  FARs,  a  system  or  component  is  subjected 
to  environmental  tests,  software  tests,  failure  analyses,  and  other  testing,  as 
deemed  necessary.  The  FAA  relies  on  the  manufacturer  to  conduct  the  testing. 
If  the  FAA  approves  new  tests,  the  manufacturer  must  comply  with  them.  These 
tests  are  identified  in  guidelines  adopted  by  the  FAA.  Organizations  such  as 
Aeronautical  Radio,  Incorporated  (ARINC) ,  Engineering  Society  for  Advancing 
Mobility  Land  Sea  Air  and  Space  (SAE) ,  and  Requirements  and  Technical  Concepts 
for  Aviation  (RTCA)  produce  such  guidelines.  Some  guidelines  which  may  be 
applied  to  Al-based  systems  are  identified  below.  Further  details  of  the 
certification  process  can  be  found  in  DOT/FAA/CT-91/19 ,  "Avionic  Data  Bus 
Integration  Technology." 

5.2.1  Hardware  Guidelines 

In  the  past,  to  certificate  an  airplane,  inspectors  and  engineers  had  to 
understand  avionics  based  on  analog  electronic  systems  driving  mechanical, 
pneumatic,  and/or  hydraulic  systems.  One  of  the  currently  used  guidelines  for 
the  certification  of  avionic  hardware  is  RTCA/DO-160C ,  "Environmental  Conditions 
and  Test  Procedures  for  Airborne  Equipment."  RTCA/DO— 160C  addresses  the  effects 
of  magnetic  fields,  voltage  spikes,  and  induced  voltages  on  electronic 
components.  Any  airborne  hardware  is  subject  to  its  requirements.  There  are 
also  a  number  of  other  issues  relating  to  hardware  that  influence  the  safety  of 
flight . 

Another  guideline  is  the  SAE's  Aerospace  Recommended  Practice  (ARP)  1834.  It 
defines  Fault  and  Failure  Analysis  (F/FA)  techniques  for  digital  hardware.  Since 
digital  systems  are  fault  prone,  the  FAA  has  decided  that  fault  analysis  should 
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be  employed  during  the  certification  process.  FAR  Parts  23,  25,  27,  and  29, 
section  1309,  and  Advisory  Circular  (AC)  25.1309-1A  express  the  need  for  fault 
analysis  and  ARP1834  has  provided  a  means  for  conducting  such  an  analysis. 

Today's  digital  systems  are  more  complex  than  those  for  which  the  tests  were 
designed.  Digital  hardware  complexity  has  increased  to  the  point  that 
traditional  design  methods  can  no  longer  be  used.  Automated  tools  are  required 
for  design,  layout,  and  testing  of  complex  ICs  and  circuit  boards.  According  to 
Keller  (1992): 

Some  electronics  systems  themselves  have  attained  a  complexity  level 
such  that  traditional  lab  and  flight  testing  methods  cannot 
realistically  be  extensive  enough  to  show  compliance  to  existing 
requirements . 

New  guidelines,  however,  may  be  adopted  in  the  future  as  a  result  of  RTCA's 
Special  Committee  (SC)  180,  which  is  formulating  design  assurance  guidance  for 
complex  electronic  hardware  used  in  airborne  systems  (RTCA  Paper  No.  548- 
93/SC180-18  1994). 

5,2.2  Software  Guidelines 

This  same  explosive  growth  that  occurred  with  digital  hardware  technology  has 
occurred  in  the  software  domain  as  well,  to  the  extent  that  "the  probability  of 
a  hazardous  error  in  software  cannot  be  quantified"  (Keller  1992) . 

Keller  identifies  three  major  issues  relating  to  certification  of  sof tware-based 
systems : 

■  Method  of  compliance  demonstration 

■  Determination  of  the  rigor  required  to  ensure  software  integrity 

■  Determination  of  the  software  contribution  to  systems  hazards 

A  method  of  compliance  demonstration  commonly  used  by  manufacturers  to  meet  FAA 
requirements  is  found  in  "Software  Considerations  in  Airborne  Systems  and 
Equipment  Certification"  (RTCA/DO-178B  1992)  .  This  document  was  prepared  by  SC 
167  of  RTCA  and  was  adopted  as  an  official  guideline  in  FAA  AC  20-115C.  Since 
software  is  generally  too  complex  to  test  for  errors,  guidance  is  given  in  this 
document  on  acceptable  processes  used  for  developing  airborne  software.  The 
software  developer  is  required  to  be  in  compliance  with  this  guideline  from  the 
initial  stages  of  development  and  must  have  the  appropriate  artifacts  to 
demonstrate  the  amount  of  development  rigor  (Keller  1992) . 

Determination  of  the  rigor  required  to  ensure  software  integrity  is  done  in 
concert  with  the  participating  ACO.  RTCA/DO-178B  defines  five  categories  of 
failure  conditions,  ranging  from  "Catastrophic"  to  "No  Effect."  Associated  with 
each  of  these  categories  is  a  corresponding  level,  ranging  from  Level  A  through 
Level  E.  Level  A,  the  most  critical  level,  is  defined  as: 

Software  whose  anomalous  behavior,  as  shown  by  the  system  safety 
assessment  process,  would  cause  or  contribute  to  a  failure  of  system 
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function  resulting  in  a  catastrophic  failure  condition  for  the 
aircraft . 

Software  that  is  determined  to  have  no  effect  on  the  crew  workload  or  the 
operational  capability  of  the  aircraft  is  defined  as  Level  E.  Once  the  software 
level  determination  is  made,  software  at  Level  E  is  not  subject  to  any  additional 
guidelines  of  RTCA/DO-178B .  The  remaining  three  levels,  from  Level  D  through 
Level  B,  define  software  having  an  increasingly  greater  effect  on  flight  safety. 

RTCA/DO-178B  addresses  guidelines  for  producing  airborne  software  that  will  meet 
airworthiness  requirements.  It  addresses  software  life  cycle  processes,  the 
activities  associated  with  those  process  objectives,  and  the  evidence  that  shows 
that  the  objectives  have  been  met.  It  is  a  document  that  addresses  all  the 
critical  stages  of  software  development. 

5.2.3  Software  Guidelines  and  Artificial  Intelligence 

5. 2. 3.1  RTCA/DO-178B 

Existing  certification  guidelines  were  not  designed  with  AI  or  knowledge-based 
software  in  view.  The  unique  characteristics  associated  with  the  development  and 
testing  of  Al-based  software  are  not  covered  in  RTCA/DO-178B ,  although  AI  has 
been  identified  as  a  technology  that  may  receive  attention  in  a  future  revision 
(DeWalt  1992).  Manufacturers  wishing  to  implement  systems  incorporating  AI  are, 
therefore,  faced  with  certain  difficulties  when  considering  the  certification 
process . 

As  an  example,  RTCA/DO-178B  requires  that  algorithms  be  checked  for  accuracy  if 
they  are  classified  at  level  A,  B,  or  C.  While  ESs  may  contain  algorithms,  they 
also  contain  knowledge  bases  which  should  be  subjected  to  the  same  processes  as 
conventional  software.  Just  as  algorithms  are  checked  for  accuracy,  knowledge 
base  accuracy  also  needs  to  be  verified.  For  software  criticality  levels  A  or 
B,  this  verification  should  be  satisfied  by  independent  verification.  This  may 
be  difficult  for  ESs,  since  domain  experts  are  scarce  and  their  knowledge  can  be 
contradictory.  In  addition,  eliciting,  capturing,  and  representing  knowledge 
from  domain  experts  can  be  a  difficult  task.  Not  even  the  expert  can  know  if  all 
the  relevant  information  has  been  embodied  in  the  knowledge  base.  Acceptable 
methods  for  knowledge  base  verification  need  to  be  addressed. 

ESs  are  similar  to  advanced  development  tools,  since  there  are  few  intermediate 
levels  when  ESs  are  viewed  from  the  requirements  level  through  the  executable 
code  level.  While  the  number  of  products  generated  during  the  development  of  ESs 
are  few  as  compared  with  conventional  software,  the  trend  in  conventional 
software  is  to  design  systems  at  higher  levels  and  reduce  the  number  of  steps  in 
the  development  process  by  using  automated  design  tools.  Regardless  of  the 
number  of  development  steps,  tool  qualification  issues  also  need  to  be  addressed, 
whether  for  conventional  or  ES-based  systems.  These  and  other  related  topics 
should  receive  coverage  in  a  future  revision  of  RTCA/DO-178. 
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5 . 2 . 3 . 2  DOD— STD— 2167A 


DOD-STD-2167A  establishes  uniform  requirements  for  software  development  over  a 
system's  life  cycle.  ES  developers  can  face  problems  when  compliance  with  DOD- 
STD-2167A  is  required.  The  software  development  cycle  described  by  DOD-STD-2167A 
is  not  descriptive  of  the  development  process  for  ESs.  The  development  process 
for  ESs  is  a  much  more  iterative  process  than  that  of  conventional  software. 
Also,  the  five  phases  of  development  are  not  independent  and  clear-cut,  but 
describe  a  knowledge  acquisition  process.  To  accommodate  knowledge-based 
systems,  a  new  development  cycle  needs  to  be  defined  and  incorporated  into  the 
appropriate  standards  (Carlton  1987) . 

5.3  Artificial  Intelligence  Standards 

Since  AI  is  a  relatively  new  technology,  a  lack  of  standardization  exists. 
Standards  relating  to  AI  are  only  beginning  to  emerge.  This  generates 
difficulties,  especially  from  the  developer's  perspective.  Adherence  to 
standards  can  have  many  benefits  for  developers,  including  interoperability 
through  common  interfaces,  as  well  as  product  portability.  Additionally,  lower 
overall  life-cycle  costs  can  be  realized  through  increased  reliability  and 
maintainability.  Areas  where  standards  could  benefit  the  technology  include 
knowledge  representation,  ES  shells,  and  AI  language  standardization. 

5.4  Conventional  Software  Verification  and  Validation 

This  section  examines  techniques,  methods,  and  issues  relating  to  the  V&V  of 
conventional  software-based  systems.  A  review  of  these  issues  is  necessary  to 
provide  the  background  and  framework  for  the  application  of  these  techniques  to 
AI— based  systems.  Once  the  issues  are  understood  for  conventional  software,  they 
can  be  applied  to  other  types  of  systems  and  tailored  for  specific 
characteristics  of  those  systems. 

Although  this  section  deals  with  software  issues,  it  is  important  to  note  that 
the  processes  described  in  this  section  can  and  should  be  applied  to  hardware, 
software,  and  systems.  New  techniques  may  be  necessary  for  ensuring  safety  goals 
for  today's  highly  integrated  and  complex  systems.  Each  component,  as  well  as 
the  total  system,  needs  to  be  subjected  to  scrutiny  that  yields  the  required 
assurance  level.  Today's  highly  integrated  avionics,  using  silicon  devices  with 
millions  of  transistors  in  a  single  package,  require  the  application  of  V&V 
techniques  specifically  designed  for  this  level  of  complexity,  just  as  ESs 
require  unique  V&V  techniques . 

5.4.1  Verification  and  Validation 

5 . 4 . 1 . 1  Verification 

There  is  no  exclusively  correct  set  of  software  statements  for  implementing 
solutions  in  software-based  systems,  since  there  are  virtually  an  infinite  number 
of  different  ways  to  represent  solutions  to  system  problems.  Since  software 
solutions  are  used  in  systems  where  failure  can  result  in  loss  of  life  and 
property,  methods  are  needed  to  demonstrate  that  the  particular  software  solution 
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chosen  to  solve  a  system  problem  is  correct  and  safe.  This  is  one  of  the 
functions  of  the  verification  process. 

According  to  the  glossary  of  the  Digital  Systems  Validation  Handbook-Volume  II, 
verification  is  defined  as: 

The  act  of  reviewing,  inspecting,  testing,  checking,  auditing,  or 
otherwise  establishing  and  documenting  whether  or  not  items, 
processes,  services,  or  documents  conform  to  specified  requirements. 

5 .4. 1.1.1  Verification  and  Documentation 

One  of  the  important  ingredients  in  the  process  of  verification  is  documentation. 
According  to  Naser  (1991),  "Documentation  creates  a  traceable  and  systematic 
approach  to  the  development  of  a  product."  Traceability  is  important  since  it 
demonstrates  the  flow  and  development  of  concepts  and  design  elements  from  the 
requirements  documents  through  the  final  product. 

When  a  system  is  well  documented,  it  can  be  understood  by  knowledgeable  persons 
other  than  the  developers.  Persons  other  than  the  developers  are  often  used  in 
the  verification  process  to  analyze  the  product  from  a  different  perspective. 
This  activity  is  referred  to  as  Independent  Verification  and  Validation  (IV&V) . 

Problems  in  the  development  process  often  appear  as  the  result  of  the  transition 
from  one  step  to  the  next.  Part  of  the  verification  process  deals  with 
determining  that  a  complete  and  accurate  translation  has  been  performed  by  the 
developers . 

A  requirements  document  describes  the  system  at  the  highest  level.  It  goes 
through  many  iterations  of  refinement  during  development.  It  also  requires 
maintenance  throughout  the  product  life  cycle. 

Traceability  depends  on  the  completeness  and  accuracy  of  the  requirements 
document.  The  requirements  document  is  viewed  as  a  set  of  external  performance 
goals.  Testing  explicitly  confirms  that  these  product  or  system  performance 
goals  can  be  met.  Testing  against  the  requirements  is  both  desirable  and 
necessary  (Naser  1991) . 

5 . 4 . 1 . 2  Validation 

The  Digital  Systems  Validation  Handbook  describes  validation  as: 

Demonstration  and  authentication  that  a  final  product  operates  in 
all  modes  and  performs  consistently  and  successfully  under  all 
actual  operational  and  environmental  conditions  founded  upon 
conformance  to  the  applicable  specifications. 

Validation  is  performed  on  p  system  to  ensure  that  the  requirements  and  the  end 
product,  operating  in  its  intended  environment,  have  a  direct  correspondence. 
Validation  is  a  process  that  is  composed  of  a  number  of  activities.  The  purpose 
is  to  demonstrate  that  a  piece  of  software  is  designed  correctly  and  that  it  is 
the  correct  or  right  design.  The  functionality,  performance,  and  device 
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interface  are  given  in  the  requirements  document.  If  the  product  does  not  meet 
these  criteria,  then  the  deficiency  can  be  traced  back  to  the  cause  through  each 
of  the  step— wise  refinements  of  the  development  process . 

One  may  deduce  at  this  point  that  errors  found  in  the  validation  phase  are  the 
most  costly  to  correct.  Since  development  proceeds  in  a  step-wise  manner,  the 
correctness  of  each  step  is  essential  to  avoiding  mistakes  that  will  ripple  down 
into  the  end  product,  where  they  are  consequently  discovered. 

5. 4. 1.3  Aspects  of  Verification  and  Validation 

5 . 4 . 1 . 3 . 1  Correctness 

There  are  several  different  aspects  of  correctness  that  require  examination. 
These  include  functional,  safety,  user-interface,  resource  consumption,  and 
utility  correctness.  Consistency,  completeness,  and  termination  are  also  aspects 
of  correctness,  but  are  examined  separately. 

5.4.1. 3.1.1  Functional  Correctness 

Functional  correctness  is  concerned  with  how  a  particular  piece  of  software 
behaves,  based  on  various  system  inputs.  This  behavior  is  defined  by  the  system 
documentation.  In  general,  it  is  not  possible  to  test  all  input  combinations 
completely.  Therefore,  a  number  of  techniques  and  rationales  exist  for 
generating  tests  that  are  the  most  beneficial  for  demonstrating  functional 
correctness  of  the  subject  software.  Test  methods  to  demonstrate  functional 
correctness  check  to  see  that  the  program  generates  the  correct  system  output  for 
any  input.  Testing  of  all  cases  is  generally  not  possible;  therefore,  only 
certain  sets  of  test  cases  are  examined.  The  preferred  set  of  tests  include 
those  that  are  most  likely  to  occur  in  normal  operation. 

There  are  several  methods  used  for  test  case  selection,  some  of  which  follow: 

■  Cause-effect  graphing  -  Consists  of  mapping  the  input  and  output  paths, 
where  the  conditions  are  expressed  in  Boolean  form.  Intermediate  steps 
are  also  shown,  yielding  an  accurate  representation  of  the  level  of 
abstraction  of  the  software. 

■  Boundary  testing  -  A  technique  used  to  test  input  boundaries  defined  in 

the  software.  Testing  the  response  using  inputs  near  the  boundary 

provides  significant  data  on  the  correctness  of  the  software. 

•  Attribute-based  test  case  selection  -  Requires  that  test  cases  are 

selected  based  on  software  characteristics.  For  instance,  a  specific  test 
case  may  be  designed  for  a  complex  part  of  the  software,  while  a  simpler 
part  may  be  passed  over.  Criticality,  as  well  as  program  size,  are 
attributes  used  for  test  case  selection. 

■  Random  testing  -  A  technique  for  test  case  selection.  As  the  name 
suggests,  the  method  of  selection  for  this  technique  is  entirely  random. 
Using  this  method,  no  rationale  is  required  for  selection  of  test  cases. 
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5. 4. 1.3. 1.2  Safety  Correctness 

Safety  correctness  deals  with  showing  that  software  never  reaches  a  state  that 
poses  a  danger  to  man  or  machine.  With  the  increasing  complexity  of  systems, 
this  attribute  may  be  easier  to  demonstrate  than  functional  correctness. 

Safety  correctness  testing  is  concerned  with  picking  tests  that  are  designed  to 
generate  unsafe  states  in  the  software.  Knowledge  of  the  controlled  device  is 
necessary  to  identify  unsafe  software  states.  Various  combinations  or  sequences 
of  inputs  are  exercised  while  the  response  is  examined  for  unsafe  conditions. 

5. 4. 1.3. 1.3  User-Interface  Correctness 

User-interface  correctness  is  concerned  with  the  end-user  and  human  factors 
aspects  of  the  software  interface.  Some  of  the  human  factors  aspects  that  are 
considered  include  ambiguity,  correctness,  and  "user-friendliness." 

5. 4. 1.3. 1.4  Resource  Consumption  Correctness 

Resource  consumption  correctness  demonstrates  that  the  software  operates 
efficiently  within  its  environment.  It  focuses  on  performance  issues,  such  as 
general  hardware  architecture,  disk  utilization,  communication  channel  bandwidth , 
and  meeting  specified  timing  constraints.  This  method  is  essentially  a 
performance  test  to  check  whether  or  not  a  system  operates  efficiently  for  its 
intended  application. 

5. 4. 1.3. 1.5  Utility  Correctness 

Utility  correctness  focuses  on  the  usefulness  of  the  system.  It  considers 
whether  or  not  it  is  the  right  system,  it  does  the  right  things,  it  does  what  the 
customer  wants,  and  it  meets  the  system  requirements. 

5. 4. 1.3. 2  Consistency 

Consistency  demonstrates  that  the  software  follows  a  predictable  path.  Two  forms 
of  consistency  are  examined:  external  and  internal.  External  consistency 

demonstrates  that  when  a  particular  event  occurs,  an  associated  routine  is 
exercised.  External  consistency  also  considers  the  user  interface.  The  look  and 
feel  should  be  consistent.  Internal  consistency  involves  showing  that  all  parts 
of  an  integrated  software  module  are  consistent. 

5. 4. 1.3. 3  Completeness 

Completeness  involves  demonstrating  that  nothing  is  missing  from  the  program. 
Completeness  seeks  to  demonstrate  properties,  such  as  the  following: 

■  The  software  accepts  and  acts  upon  all  data. 

■  The  software  generates  all  required  outputs. 

■  The  software  performs  all  required  actions. 
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There  are  no  algorithms  that  can  be  exercised  to  demonstrate  completeness. 
Sufficient  completeness  should  be  demonstrated  to  show  that  the  requirements  are 
satisfied. 

5 . 4 . 1 . 3 . 4  Termination 

Another  aspect  of  correctness  is  the  demonstration  of  termination.  This 
characteristic  ensures  that  a  program  will  always  end.  Demonstration  of 
termination  is  done  by  showing  that  all  looping  structures  within  the  program 
terminate  (French  and  Hamilton  1992) . 

5.4.2  Verification  and  Validation  Testing  Phases 

Testing  is  beneficial  for  several  reasons: 

■  Both  major  and  minor  errors  can  be  identified. 

■  Errors  introduced  into  the  system  can  be  reduced. 

■  Confidence  in  the  product  can  be  increased. 

This  section  discusses  classes  of  testing  performed  on  software,  including  static 
and  dynamic  testing.  Testing  methods  are  also  discussed. 

5. 4. 2.1  Static  Testing 

While  dynamic  testing  involves  running  the  software  in  the  target  environment, 
static  testing  involves  analyzing  the  software  by  methods  other  than  execution 
of  the  code.  Static  testing  is  done  either  by  software  review  or  by  using  tools 
to  analyze  the  software.  A  detailed  examination  of  the  equations  contained  in 
the  software  is  performed,  or  other  checks  are  made  against  the  specification. 

The  static  testing  method  is  the  most  cost  effective  since  it  occurs  early  in  the 
development  phase.  As  software  development  proceeds  from  the  requirements  phase 
to  the  system  test  phase,  the  cost  of  fixing  errors  increases  drastically. 
Errors  identified  and  corrected  in  the  requirements  phase  have  the  smallest 
impact  on  the  overall  development. 

5. 4. 2. 2  Dynamic  Testing 

Dynamic  testing  is  testing  of  the  software  in  its  intended  operational  (target) 
environment.  Dynamic  testing  has  two  parts:  system  testing  and  uni t/integration 
testing.  This  testing  method  is  the  least  cost  effective  since  it  is  performed 
later  in  the  development  phase.  Errors  identified  and  corrected  in  this  phase 
of  testing  have  a  larger  impact  on  the  overall  development  cost  and  schedule. 
Detailed  verification  at  the  requirements  phase  can  greatly  reduce  the  amount  of 
rework  that  may  otherwise  be  performed  in  later  stages  of  the  development 
process . 

5. 4. 2. 2.1  Integration  Testing 

Integration  testing  is  referred  to  as  a  "white  box"  testing  technique  (French  and 
Hamilton  1992).  It  is  dynamic  and  focuses  on  Input/Output  (I/O)  response 
classes.  Integration  testing  can  deal  with  multiple  levels  of  abstraction, 
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whereas  system  testing  deals  with  only  one.  This  technique  is  concerned  with  the 
correctness  of  the  unit. 

Integration  testing  depends  on  modularity  of  the  software.  Modularity  implies 
that  the  design  and  development  process  can  be  simplified  by  breaking  a  large  and 
complex  task  into  smaller  but  more  manageable  pieces.  Each  piece  can  be  handled 
by  a  different  person  or  group,  and  can,  after  thorough  testing,  be  integrated 
with  the  other  pieces.  Modularity  is  a  benefit  to  verification  in  that  when 
changes  are  made,  only  the  module  that  is  changed  needs  to  be  verified. 

5. 4. 2. 2. 2  System  Test 

The  system  test  is  the  last  test  to  be  performed.  It  is  the  final  step  in  the 
development  process.  Demonstrating  correctness  at  this  stage  does  not  require 
knowledge  of  the  internals  of  the  Unit  Under  Test  (UUT) .  It  is  simply  treated 
as  a  "black  box."  This  black  box  is  tested  to  see  that  the  behavior  it  exhibits 
is  correct.  The  responses  of  the  black  box  are  based  on  the  original 
requirements  that  were  established  with  the  customer.  The  contents  of  the  box 
are,  at  this  point,  irrelevant  and  not  the  subject  of  any  investigation. 
Independent  verification  is  desirable,  since  knowledge  of  the  internals  are 
irrelevant  during  system  test  and  may  be  a  stumbling  block  to  testers. 

It  is  generally  accepted  that  complete  testing  of  software  is  not  possible.  This 
is  due  to  the  fact  that,  for  any  given  system,  there  are  too  many  I/O  responses 
to  be  tested.  Complete  testing  of  a  system  is  not  done,  and,  therefore,  it  is 
unknown  whether  or  not  the  software  in  the  black  box  is  completely  correct. 

In  order  to  devise  practical  limits  on  the  number  of  I/O  responses  to  be  checked 
during  testing,  the  software  in  the  black  box  can  be  divided  into  categories 
based  on  the  classification  of  the  I/O  responses.  These  individual  categories 
can  then  be  treated  as  separate  units  and  tested  as  though  each  were  its  own 
separate  box. 

5. 4. 2. 3  General  Testing  Methods 

The  three  general  methods  of  testing  are  prototyping,  regression  testing,  and 
IV&V .  Prototyping  involves  building  a  scaled  version  of  the  real  system.  This 
is  then  used  to  evaluate  the  operation  of  the  system.  Regression  testing 
involves  testing  older  software  that  has  undergone  modification.  It  ensures  that 
the  modified  portions  of  software  do  not  affect  other  portions  that  were  not 
changed.  IV&V  is  a  testing  method  that  calls  for  an  organization  not  involved 
in  a  product's  development  to  perform  the  V&V.  This  method  seeks  to  avoid 
prejudice  towards  that  particular  product  on  the  part  of  the  developers. 

5.5  Expert  System  Software  Verification  and  Validation 

V&V  is  an  essential  activity  for  any  system  where  software  criticality  is  an 
issue.  V&V  is  as  important  for  ESs  as  it  is  for  any  software  system.  The 
adaptation  of  existing  V&V  methodologies  to  ESs  requires  an  appreciation  of  the 
risks  inherent  in  the  particular  implementation  just  as  it  does  for  conventional 
software.  The  variation  in  ES  applications  and  implementation  covers  a  wide 
range  just  as  it  does  for  conventional  software.  The  V&V  testing  should  be 
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planned  accordingly.  In  many  cases,  an  ES  will  require  less  effort  to  validate 
than  a  conventional  software  application  of  comparable  complexity.  Methodologies 
for  V&V  of  ESs  is  an  area  of  ongoing  research. 

Conventional  V&V  techniques  can  and  should  be  used  for  parts  of  an  ES ,  such  as 
the  inference  engine;  particularly  if  the  inference  engine  is  implemented  with 
conventional  software.  However,  the  knowledge  base  is  substantially  different 
from  conventional  software  implementations  requiring  the  application  of  new  V&V 
techniques . 

ES  applications  that  are  limited  in  scope,  having  fixed  and  easily  verifiable 
knowledge  bases,  should  require  significantly  less  V&V  effort  than  those  dealing 
with  pilot  intent  interpretation.  Software  modules  of  the  PA  need  to  be 
subjected  to  more  intense  V&V  because  of  the  scope  of  the  PA,  the  information  the 
PA  has  as  input  (such  as  pilot  intent),  and  the  capability  of  the  PA  to  exert 
control  over  other  aircraft  systems.  A  diverter  ES ,  on  the  other  hand,  is  much 
more  limited  in  scope,  deals  with  trustworthy  data  at  the  input  (such  as  the  AIM 
and  FARs) ,  and  offers  advice  without  exerting  control  over  other  systems. 

In  general,  ES  applications  proposed  for  commercial  aircraft  have  limited 
complexity.  However,  this  report  presents  V&V  techniques  that  address  simple, 
as  well  as  complex  ESs.  One  of  the  tasks  of  the  certification  specialist  is  to 
determine  the  required  level  of  testing  based  on  the  proposed  application  of  the 
ES. 

5.5.1  Contrasting  Expert  Systems  and  Conventional  Software 

The  types  of  problems  that  ESs  are  used  to  solve  are  highly  complex  and  too 
difficult  to  solve  by  conventional  computer  methods . 

For  these  problems,  a  solution  exists  in  the  mind  of  the  expert.  This  solution 
is  derived  by  application  of  the  expert's  domain  knowledge.  This  knowledge  is 
then  translated  by  the  knowledge  engineer  into  terms  that  a  computer  can 
understand.  The  manner  by  which  problems  are  represented  and  solved  constitutes 
the  fundamental  differences  between  ESs  and  conventional  software. 

5. 5. 1.1  The  Software  Development  Cycle 

While  many  techniques  that  are  used  for  V&V  of  conventional  software  can  be 
applied  to  ESs,  there  remain  areas  where  new  techniques  are  required.  Some  of 
the  differences  are  examined  in  the  following  sections .  In  spite  of  the 
differences  between  ES  and  conventional  software  development,  ESs  demonstrate  a 
recognizable  life  cycle.  There  are  well  defined  steps  within  this  cycle  to  which 
V&V  techniques  can  be  applied. 

Specifications  and  design  documents  are  as  necessary  for  ES  development  as  they 
are  for  conventional  software.  Performance  goals  and  functionality  are  measured 
against  these  documents.  To  implement  any  verification  technique,  an  objective 
for  a  project  must  exist  and  be  well  documented.  Without  an  objective,  there  is 
little  help  for  the  developer  and  no  hope  for  the  verification  effort. 
Traceability  requirements  start  with  concrete  measurable  objectives.  From  this 
point,  further  refinements  are  made  until  the  requirements  are  well-defined. 
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As  the  system  is  developed,  document  maintenance  is  required.  ES  requirements 
often  emerge  throughout  the  development  cycle,  necessitating  incremental  build 
and  test  cycles.  According  to  Naser  (1991): 

Testing  the  prototype  reveals  deficiencies  in  performance,  suggests 
holes  in  the  knowledge  base,  and  stimulates  another  round  of 
knowledge-building,  coding,  and  testing. 

5. 5. 1.1.1  Development  Complexity 

The  power  that  an  ES  shell  environment  offers  the  developer  and  the  user  is  often 
employed  in  developing  applications  far  more  complex  than  would  ever  be 
contemplated  using  a  conventional  software  approach.  This  is  usually  manifested 
by  a  large  number  (many  hundreds)  of  rules  in  an  attempt  to  model  a  complex 
process  with  extremely  high  fidelity. 

If  the  application  is  so  difficult  that  only  a  powerful  approach  can  hope  to 
succeed,  the  problem  of  V&V  comes  from  the  scope  of  the  application,  not  from  the 
approach.  A  program  such  as  the  PA  has  very  difficult  goals,  regardless  of  the 
development  technique.  An  ES  approach  to  the  PA  reduces  the  complexity  of  the 
overall  task. 

As  with  the  verification  of  any  critical  and  complex  software  application,  the 
V&V  approach  must  include  an  assessment  of  the  risks  to  correct  performance  and 
direct  attention  to  minimizing  exposure  to  these  risks.  A  major  risk  that  is 
avoided  with  an  ES  approach  is  the  integrity  of  the  logic  applied  to  the  rules 
in  the  application.  The  V&V  effort  should  also  focus  on  the  question  of  the 
integrity  and  fidelity  of  the  rules  relative  to  the  problem  domain.  This  effort 
is  tenable,  even  when  there  are  a  large  number  of  rules.  This  is  because  the 
rules  are  in  the  form  of  English-like  statements,  and,  more  importantly,  the 
logic  taken  by  the  application  on  test  cases  can  be  examined  minutely. 

The  complexity  of  the  internal  interactions  of  a  software  system  depends  not  so 
much  on  the  implementation  technique,  but  on  how  the  developer  has  applied  the 
technique.  Programs  written  in  C  can  be  as  cryptic  as  the  developer  chooses. 
ES  internal  interactions  that  are  complex  need  to  receive  greater  attention  in 
verification  activity  so  that  all  consequences  are  known.  It  is  possible  to 
design  ESs  that  have  a  more  structured  appearance  and,  therefore,  facilitate 
testing. 

In  some  cases,  the  inference  engine  may  be  implemented  using  LISP.  When  this  is 
the  case,  the  developer  may  be  required  to  implement  a  garbage  collection  scheme. 

Table  5.5-1  summarizes  some  of  the  major  differences  between  ESs  and  conventional 
software . 

5. 5. 1.1. 2  Determination  of  Correctness 

It  is  difficult  to  determine  the  correctness  of  a  system  that  generates  solutions 
based  on  the  heuristics  of  an  expert.  The  domain  expert  is  the  only  person 
qualified  to  comment  on  the  correctness  of  the  ES .  Knowledge  base  verification 
will  be  a  key  focal  point  of  certification  activity  for  critical  software. 
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TABLE  5.5-1.  EXPERT  SYSTEM  AND  CONVENTIONAL  SOFTWARE 
DIFFERENCE  SUMMARY 


Expert  Systems 

Conventional  Software 

■ 

Context  driven,  nonprocedural 

• 

Sequential  execution, 
procedural 

■ 

High-level,  abstract  data 
representation 

■ 

User-generated  data 
representation 

■ 

More  complex  internal 
interactions 

■ 

More  decisions 

■ 

May  require  garbage  collection 

■ 

More  control  structures 

■ 

Rule  interaction 

■ 

Program  dependent  internal 
interaction 

• 

Intelligent  control  behavior 

■ 

Complexity 

• 

Iterative  development 

■ 

Stepwise  deve 1 opment 

5. 5. 1.1. 3  Expert  System  Shells 

As  is  the  case  with  conventional  software  compilers,  ES  shells  may  contain 
misleading  documentation  or  exhibit  faulty  operation.  Schultz  and  Geissman1 
(1991)  point  out  that  these  potential  problems  may  ultimately  lead  to  incorrect 
operation  of  the  developed  system  if  they  go  unnoticed.  To  develop  reliable 
systems,  the  knowledge  base,  database,  and  user-generated  code,  as  well  as  the 
developer's  tools  need  to  be  validated. 

Paradigms  (such  as  chaining)  implemented  in  the  tool  need  to  be  identified.  The 
tool  then  needs  to  be  examined  to  see  if  the  paradigms  are  carried  out  correctly. 
The  importance  of  a  validated  ES  shell  cannot  be  over-emphasized,  since  the 
attributes  and  capabilities  of  a  system  are  influenced  and  limited  by  the  weakest 
link  of  that  system.  All  parameters  of  the  tools  that  affect  the  operation  or 
timing  of  the  end  product  must  be  known  and  specified. 

The  easiest  kinds  of  ESs  to  validate  are  those  developed  with  an  established 
commercial  ES  shell.  These  environments  feature  built-in  rule  editing  and  data 
management,  graphics  interfacing,  and  accessibility  by  direct  incorporation  of 
user  written  C  code.  They  also  support  justification  of  answers  by  displaying 
on  request  the  chain  of  rules  by  which  they  have  come  to  a  conclusion.  Since  the 
language  that  these  ESs  execute  is  in  the  form  of  English-like  rules,  the  process 
of  verifying  the  correctness  of  the  program  logic  is  greatly  simplified.  Both 
the  accessibility  of  the  language  and  the  justification  feature  make  it  possible 
to  achieve  a  level  of  confidence  that  an  ES  application  developed  and  supported 
by  such  an  ES  shell  does  what  was  intended  and  with  high  reliability. 
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5. 5. 1.1. 4  Inference  Engine  Verification  and  Validation 

In  the  past,  ES  users  created  their  own  ESs  using  conventional  software.  In  so 
doing,  they  also  programmed  the  inference  engine.  While  the  availability  of 
commercial  ES  shells  has  greatly  reduced  the  number  of  custom  ESs ,  when  this  is 
the  case,  and  the  application's  reliability  is  critical,  the  V&V  effort  should 
also  extend  to  the  inference  engine.  This  is  all  the  more  true  if  the  code  and 
the  knowledge  base  for  the  inference  engine  are  to  be  maintained  by  the  customer. 
Since  ES  shells  contain  inference  engines,  using  a  commercially  available  shell 
for  system  development  can  reduce,  if  not  eliminate,  the  need  for  conventional 
programming.  Also,  the  time  to  develop  a  system  can  be  reduced  by  using  a 
commercially  available  shell. 

At  a  fundamental  level,  an  inference  engine  matches  antecedents  of  some  rules 
with  the  consequences  of  others  in  what  is  interpreted  as  a  logical  sequence  of 
reasoning.  The  testing  of  an  inference  engine  involves  developing  a  suite  of 
rules  whose  behavior  is  well  understood  and  encoding  them  into  the  form  required 
by  the  inference  engine.  The  test  would  be  designed  to  show  that,  at  a  high 
level  of  confidence,  all  the  possible  connections  between  rules  are  explored  in 
arriving  at  the  conclusion  to  tests.  The  fact  that  the  same  answers  are  received 
by  the  inference  engine  under  study  as  are  received  by  the  trusted  inference 
engine  should  give  high  confidence  that  the  inference  engine  is  trustworthy. 

5. 5. 1.1. 5  Flow  Control 

Knowledge-based  systems  are  more  context  driven  than  systems  developed  with 
conventional  software.  Testing  is  more  time  consuming  when  context  driven 
software  is  used  due  to  an  increase  in  the  number  of  branches  that  require 
inspection.  For  verification  purposes,  it  is  easier  if  flow  is  determined  at 
design  time,  as  with  conventional  software. 

5. 5. 1.1. 6  Implementation  Language 

Conventional  software  is  developed  using  procedural  languages  such  as  Ada,  C, 
Pascal,  or  FORTRAN.  Knowledge-based  systems  use  a  combination  of  both  non¬ 
procedural  and  procedural  languages. 

5. 5. 1.1. 7  Deterministic  Behavior 

A  knowledge-based  system  is  deterministic,  unless  learning  is  designed  into  the 
system.  Hammer  (1991)  indicates  that  it  would  be  difficult  to  verify  that  a 
system  incorporating  learning  behaves  safely  at  all  times .  Deterministic 
behavior  must  be  demonstrated  for  ESs  and  conventional  software  systems. 

5. 5. 1.1. 8  Use  of  Dynamic  Memory 

Computer  programs  often  allocate  memory  from  a  "heap"  when  memory  resources  are 
required  during  the  execution  of  various  software  procedures .  For  verified 
software,  there  should  exist  a  statically  determined  upper  bound,  so  that  a 
routine  requiring  memory  will  never  lack  this  resource.  This  memory  allocation 
should  be  determined  during  the  design  phase. 
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5. 5. 1.1. 9  Domain  Knowledge  Review 

In  order  for  knowledge  to  be  utilized  by  a  computer,  it  is  transformed 
extensively.  A  detailed  review  for  correctness  should  be  performed  by  the  domain 
expert  before  translation.  After  undergoing  transformation  for  use  in  a  computer 
system,  the  original  knowledge  is  in  concealed  form  and  the  transformation 
process  and  product  should  be  carefully  examined. 

5.5.1.1.10  Verification  of  Knowledge-Based  Requirements 

Requirements  specify  system  behavior.  Understanding  intelligence  well  enough  to 
specify  its  interactions  in  a  requirement  document  is  difficult.  Intelligent 
behavior  consists  of  adaptivity,  not  simply  complexity.  Therefore,  verification 
of  a  knowledge-based  system  should  involve  the  testing  of  intelligent  control 
behavior. 

5.5.1.1.11  Program  Structure 

It  has  been  suggested  that  another  difference  between  ESs  and  conventional 
software  is  that  ESs  are  unstructured  while  conventional  software  is  structured. 
While  certain  High-Order  Languages  (HOLs),  such  as  Pascal  and  C,  are  referred  to 
as  structured  languages,  the  degree  to  which  a  program  reflects  this 
characteristic  is  dependent  upon  the  programmer  exercising  it.  Software  whose 
native  language  is  not  structured  can  be  implemented  in  a  structured  manner  by 
the  programmer.  What  matters  for  ESs,  as  for  conventional  software,  are  the 
techniques  used  to  implement  a  software  application. 

A  related  issue  is  the  modularity  of  the  system.  With  conventional  software, 
tracing  system  development  from  the  requirements  to  the  code  demands  the  use  of 
a  hierarchical  structure.  A  technique  called  structured  design  is  used.  When 
this  method  is  followed,  procedures  are  generated  in  a  top-down  incremental 
fashion.  In  the  past,  rule-based  ESs  have  lacked  the  hierarchical  structure  of 
conventional  software.  Rules  were  intermixed  with  each  other  and  with  control 
rules  since  no  standard  techniques  or  development  tools  existed  to  assist  in 
achieving  the  goal  of  modularity.  Modern  design  tools,  however,  allow  rules  to 
be  categorized  into  classes  by  the  designer.  The  ability  to  express  the  high 
levels  of  abstraction  made  possible  with  ESs  allows  designers  to  structure  the 
knowledge  base,  along  the  most  natural  divisions  that  exist,  as  part  of  the 
knowledge . 

5.5.2  Specification  and  Development  Differences 

Compared  with  conventional  software,  the  number  of  design  stages  in  an  ES 
development  project  will  be  fewer  due  to  the  high  level  of  expressiveness.  The 
language  of  the  ES  operates  at  a  much  higher  level  than  that  of  conventional 
software  and  may  appear  more  like  a  requirements  document  than  code.  This  is  a 
benefit  for  ESs,  since  the  verification  process  is  concerned  with  the  details  of 
fewer  intermediate  steps.  The  number  of  associated  documents  will  also  be  fewer 
than  for  conventional  software. 


20-83 


5. 5. 2.1  Vaguely  Specified  Systems 

V&V  of  ESs  is  difficult  when  there  is  uncertainty  that  the  rules  in  the  knowledge 
base  properly  represent  the  best  approach  to  a  problem.  This  situation  arises 
when  the  problem  domain  is  not  fully  understood.  When  a  knowledge  base  is 
developed  by  interviewing  an  expert  who  is  unwilling  or  unable  to  define  the 
processes  used  in  solving  a  problem,  it  is  up  to  a  knowledge  engineer  to 
translate  that  knowledge  into  rules.  Even  with  a  cooperative  and  articulate 
expert,  the  process  of  refining  a  rule  base  can  falter  when  the  effort  to  make 
explicit  expertise  reaches  the  intuition  level.  It  is  frequently  at  the 
intuitive  level  that  the  performance  of  an  expert  is  distinguished  from  that  of 
a  rule-follower. 

Challenges  to  the  V&V  effort  result  when  the  requirements  for  the  system,  and 
specifications  to  which  the  system  was  developed,  lack  detail.  The  performance 
of  the  knowledge  base  must  then  be  tested  empirically,  with  the  proof  involving 
the  approval  of  experts  in  the  problem  domain.  The  problems  of  verification  are 
not  insurmountable  if  the  inference  engine  is  verified  independently  and  there 
is  a  large  number  of  tests,  perhaps  developed  by  domain  experts,  for  which  the 
answers  are  independently  known. 

5.5.3  Implementation  Differences 

Conventional  software  and  ESs  are  similar  in  that  both  consist  of  software  which 
executes  on  a  digital  computer.  There  are  associated  inputs  and  outputs  for  any 
software  system.  An  Al-based  system  or  ES  may  even  use  a  conventional  HOL. 
Parts  of  the  ES  are  typically  implemented  using  conventional  software. 

Normally,  the  ES  user  develops  ES  applications  through  the  use  of  tools.  A 
common  tool  is  the  ES  shell.  The  ES  shell  gives  developers  the  capability  to 
create  systems  without  using  procedural  languages.  Additionally,  the  problems 
that  are  solved  using  ESs  have  different  characteristics.  To  be  effective,  the 
V&V  approach  and  activity  should  be  tailored  to  address  these  differences . 

Procedural  programs  use  a  sequence  of  executed  statements  which  are  followed 
easily.  The  next  statement  to  be  executed  in  a  sequence  is  based  on  the  value 
of  a  defined  set  of  variables.  With  non-procedural  languages,  the  execution  flow 
is  not  determined  as  easily.  This  is  due  to  the  characteristics  of  the  inference 
engine  used  to  control  execution.  Data  and  control  are  partitioned  in  ESs.  The 
j-*0fice  engine  determines  what  statement  is  executed  next  by  taking  into 
account  the  basic  state  of  the  program  together  with  the  data.  Partitioning  for 
the  knowledge  base  and  built-in  traceability  tools  for  the  shell  assist 
developers  in  generating  systems  where  the  execution  flow  can  be  traced  and 
explained  easily. 

Tool  performance  limitations  may  become  a  factor  in  the  development  process  for 
ESs,  as  also  may  be  the  case  for  conventional  software.  There  are  performance 
variables  associated  with  tools  that  are  not  apparent  to  the  developers  until 
actual  real-time  operation  of  the  program. 

All  software  is  developed  iteratively.  ESs,  however,  require  greater  amounts  of 
iteration  in  the  development  process  since  development  involves  extracting 
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Information  from  the  mind  of  domain  experts.  Many  of  the  design  assumptions  made 
during  early  stages  of  development  will  undergo  changes  during  the  ES  development 
cycle.  Therefore,  an  incremental  approach  to  development  is  viewed  as  necessary. 

It  must  be  said,  however,  that  current  conventional  software  development  allows 
a  far  greater  degree  of  iteration  than  in  the  past.  New  techniques  and  tools, 
such  as  Object-Oriented  programming,  applied  to  the  development  of  conventional 
software  systems  have  allowed  rapid  and  iterative  development  cycles  which  former 
methods  could  not  support. 

5.5.4  Verification  and  Validation  Techniques  for  Expert  Systems 

There  are  a  number  of  techniques  used  for  V&V.  No  single  technique  will  be 
efficient  for  all  applications.  Different  types  of  errors  and  characteristics 
are  tested  with  each  technique.  Two  general  approaches  exist.  One  examines 
characteristics  of  the  ES  implementation.  The  other  examines  whether  or  not  the 
solution  fits,  or  solves,  the  problem.  This  approach  is  implementation 
independent.  The  former  method  is  called  a  "clear  box"  technique,  as  opposed  to 
the  black  box  technique.  Both  techniques  are  essential. 

V&V  methods  are  sometimes  classified  into  two  groups:  qualitative  and 
quantitative.  A  qualitative  method  applies  "subjective  comparisons  of 
performance"  to  the  ES .  A  quantitative  method  uses  statistical  techniques  for 
comparison  of  ES  performance  against  test  cases  or  experts. 

O'Keefe,  Balci,  and  Smith  (1991)  divide  the  quantitative  validation  method  into 
two  categories:  one  uses  a  confidence  interval  and  the  other  uses  a  hypothesis 
test.  The  confidence  interval  is  compared  subjectively  with  an  acceptable 
performance  range,  whereas  the  hypothesis  test  is  a  formal  test  that  compares 
measurements  against  a  predetermined  acceptable  performance  range. 

A  conventional  software  subroutine  that  manipulates  variables  passed  to  it  based 
upon  a  mathematical  procedure,  will  produce  a  solution  for  which  only  a  single 
value  or  set  of  values  is  the  correct  result.  Hence,  correctness  is  easily 
tested.  A  difficulty  often  arises  with  ESs  because  there  may  be  more  than  one 
correct  solution  to  a  problem.  What  constitutes  an  acceptable  or  unacceptable 
solution  from  the  system  should  be  defined  clearly  before  verification  begins 
(Schultz  and  Geissman1  1991) . 

Table  5.5-3  summarizes  some  V&V  techniques  for  ESs  (Naser  1991). 

5. 5. 4.1  Testing  the  Implementation 

Testing  the  implementation  involves  checking  interactions  to  see  if  they  are 
intended  and  correct.  In  systems  where  there  is  a  large  amount  of  interaction, 
this  can  be  a  difficult  task.  Several  techniques  for  implementation  testing  are 
examined  in  this  section.  These  techniques  do  not  identify  errors,  but  provide 
an  indication  that  an  error  may  exist.  It  is  then  up  to  the  programmer  or  domain 
expert  to  determine  if  the  error  actually  exists. 
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TABLE  5.5-3.  EXPERT  SYSTEM  VERIFICATION  AND  VALIDATION  TECHNIQUES 


■  Formalize  the  requirements  in  a  specification  document. 

■  Verify  that  the  requirements  specification  captures  the  requirements, 
including  those  for  system  usability. 

■  Verify  that  the  requirements  specification  is  implemented  in  the 
system  design. 

■  Verify  that  the  design  is  maintainable. 

■  Verify  adequacy  of  knowledge  and  accuracy  of  knowledge  presentation. 

•  Verify  that  the  requirements  are  met  for  all  interfaces  of  the 

system. 

■  Verify  rule  completeness  and  consistency. 

■  Conduct  comprehensive  shakedown  testing,  exercising  as  much  of  the 
system  as  possible. 

■  Verify  system  usability. 

■  Conduct  tests  for  special  cases  and  boundary  conditions. 

•  Verify  that  the  system  is  useful  and  fulfills  its  design  purpose. 


Testing  ESs  can  be  similar  to  testing  conventional  software.  Testing 
conventional  software  can  be  performed  by  exercising  decision  branches,  checking 
looping  conditions,  and  testing  boundary  conditions.  Applied  to  ESs,  these 
techniques  could  be  mirrored  by  testing  every  rule  or  sequence  of  rules,  if  the 
rule  base  is  not  too  large,  and  exercising  rules  based  on  the  rule  conditions. 
Additionally,  just  as  conventional  software  is  tested  for  quality  of 
implementation,  ESs  should  be  checked  for  problem  indicators.  These  include 
obscure  constructs,  overlapping  rules,  incongruous  rules,  incomplete  rule 
coverage,  and  infinite  rule  loops  (Hammer  1991). 

5. 5. 4. 1.1  Testing  Rule  Consistency 

Rule  consistency  checks  for  the  absence  of  undesirable  characteristics  in  ES 
implementations.  These  characteristics  include  the  following: 

■  Dead-ends  -  A  rule  that  has  no  effect  on  any  other  rules. 

•  Unreachable  rules  -  Rules  that  are  not  affected  by  any  other  rule. 

■  Circular  rules  -  Rules  that  have  the  potential  to  repeat  endlessly. 
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■  Conflicting  rules  -  Rules  that  contradict  each  other  and  perform  actions 
which  are  in  opposition. 

■  Redundant  rules  -  Rules  that  contain  the  same  information  and  perform  some 
of  the  same  actions  as  other  rules.  Although  redundant  rules  may  not 
actually  produce  errors,  they  should  be  identified  and  checked. 

5. 5. 4. 1.2  Testing  Data  Consistency 

Data  consistency  involves  checking  that  data  or  facts  are  used  as  defined.  An 
operation  that  writes  a  16-bit  value  into  a  variable  defined  as  only  8  bits  would 
be  detected  by  such  a  check. 

5.5.4. 1.3  Sensitivity  Analysis 

Sensitivity  analysis  is  an  examination  of  how  one  variable  may  influence  other 
variables.  This  type  of  analysis  is  useful  in  classifying  problem  solutions 
(French  and  Hamilton  1992) . 

5. 5. 4. 1.4  Structural  Testing 

Structural  testing  is  performed  to  ensure  that  a  set  of  tests  is  comprehensive 
in  coverage.  This  type  of  testing  can  be  adapted  to  ESs  by  defining  coverage  to 
include  rules,  frames,  and  frame  demons  (procedures  activated  by  changing  or 
accessing  frame  data).  When  changes  are  made  to  the  knowledge  base,  the  coverage 
again  must  be  determined  and  new  tests  created  and  executed. 

5. 5. 4. 1.5  Specification-Directed  Analysis 

Specification-directed  analysis  is  a  method  for  demonstrating  that  a  program  is 
traceable  to  the  specification  from  which  it  was  produced.  This  is  performed  by 
first  arriving  at  a  method  which  identifies  and  records  specif ications .  These 
identified  specification  items  are  then  checked  against  the  program  for 
correspondence . 

In  addition,  the  knowledge  represented  needs  to  be  adequate  for  the  intended  use 
of  the  system.  This  requirement  helps  define  test  cases  so  that  test  coverage 
will  be  complete.  When  incorrect  responses  are  found  in  the  system,  it  should 
not  be  difficult  to  trace  the  incorrect  response  to  its  origin. 

5. 5. 4. 2  Test  Bias  Elimination 

Biases  in  testing  should  be  avoided,  where  possible.  One  particular  bias  is  the 
use  of  test  cases  that  were  used  during  the  development  process.  Presumably,  the 
system  was  designed  in  such  a  way  that  it  responds  favorably  to  these  tests.  For 
completeness,  some  of  these  tests  should  be  used  to  ensure  that  they  still  work. 
However,  testing  should  focus  on  areas  in  which  development  testing  has  not  been 
performed. 

As  with  conventional  software,  validation  and  testing  should  be  performed  by  a 
team  independent  of  the  development  process  to  avoid  prejudice. 
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5. 5. 4. 3  Test  Coverage 

For  conventional  software,  the  sequence  of  execution  corresponds  to  the  high 
level  code.  In  an  ES ,  the  exact  sequence  of  execution  may  be  difficult  to 
determine  by  inspection.  This  becomes  an  issue  since  it  adds  to  the  difficulty 
of  determining  test  coverage  for  verification.  However,  the  sequence  of 
execution  is  known  after  execution,  since  ESs  can  justify  their  reasoning  by 
showing  the  chain  of  logic  used  to  reach  a  conclusion. 

5. 5. 4. 4  Expert  System  Black  Box  Techniques 

Black  box  techniques  examine  whether  or  not  the  solution  of  a  particular  problem 
fits,  or  solves,  that  problem.  They  are  independent  of  any  implementation 
language  or  design. 

5. 5. 4. 4.1  Knowledge  Acquisition  Checking 

The  earliest  that  errors  in  knowledge  are  introduced  into  the  development  process 
is  in  the  acquisition  of  knowledge  from  the  expert.  Errors  at  this  stage  may  be 
kept  to  a  minimum  by  testing  the  expert  knowledge  for  completeness.  This  can  be 
accomplished  by  checking  for  the  following  (French  and  Hamilton  1992): 

■  Tasks  which  are  defined  but  have  no  associated  goal 

•  Goals  that  are  defined  with  no  associated  task 

■  Undefined  terms 

■  Conditions  for  which  no  goal  or  task  is  defined 

5. 5. 4. 4. 2  Knowledge  Consistency 

Consistency  of  the  supplied  knowledge  is  also  the  focus  of  V&V  techniques.  This 
involves  checking  for  contradictory  or  redundant  statements. 

5. 5. 4. 4. 3  Knowledge  Representation 

Representing  knowledge  in  a  form  easily  understood  by  both  the  expert  and  the 
knowledge  engineer  is  essential  to  the  verification  process.  Some  techniques 
that  can  be  used  to  simplify  the  representation  of  knowledge  include  state 
tables,  concept  maps,  and  task  time  lines  (French  and  Hamilton  1992). 

5. 5. 4. 5  Formal  Verification  of  Expert  Systems 

Formal  methods,  a  technique  designed  for  verification  of  conventional  software, 
can  also  be  used  in  verification  of  ESs.  This  technique,  described  as  an 
alternative  technique  in  RTCA/DO-178B ,  can  be  used  to  satisfy  airborne  software 
certification  requirements.  According  to  Rushby  and  Whitehurst  (1989),  this 
technique  "can,  in  principle,  guarantee  the  absence  of  faults."  Its  application 
involves  demonstrating  consistency  between  two  different  descriptions  of  a 
program.  This  can  be  done  using  two  different  levels  of  program  specifications, 
or  by  using  the  program  itself  along  with  the  program  specif ication . 

Consistency  can  be  demonstrated  by  the  working  out  of  a  formal  mathematical 
proof,  when  the  two  parts  are  treated  as  formal  mathematical  texts.  One  way  this 
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technique  can  be  applied  is  by  using  a  "stacked"  application  of  verification 
steps.  Conventional  software  breaks  down  into  a  number  of  steps  during  the 
development  process.  It  is  possible  to  represent  each  specification  level 
formally  and  to  demonstrate  that  each  successive  level  demonstrates  consistency 
with  the  prior  level. 

The  use  of  formal  methods  is  a  promising  technique,  but  requires  further 
research.  The  formal  methods  technique  can  be  time  consuming  and  difficult,  and, 
therefore,  expensive  to  apply.  Since  this  is  so,  formal  methods  are  typically 
reserved  for  critical  applications,  where  reliability  and  safety  issues  are 
primary  considerations.  This  technology  would  benefit  from  guidelines  or 
standards  for  expressing  knowledge  that  needs  to  be  cast  into  the  formal 
verification  mold.  In  addition,  the  development  and  use  of  suitable  tools  could 
assist  ES  implementers  in  producing  systems  with  greater  reliability. 

5. 5. 4. 6  Other  Verification  Techniques 

Other  black  box  methods  used  in  V&V  of  ES s  include  expert  review,  minimum 
competency  testing,  and  disaster  testing.  Expert  review  is  necessary  for  systems 
requiring  V&V.  By  definition,  the  expert  already  has  an  understanding  of  the 
problem  to  be  solved  and  may  be  able  to  work  out  solutions  to  test  cases.  Having 
the  implementation  in  a  form  easily  understood  by  the  expert  is  essential  to  this 
phase  of  the  review. 

A  minimum  competency  testing  of  an  ES  involves  testing  the  system  in  much  the 
same  way  as  humans  are  tested  for  proficiency.  A  number  of  different  scenarios 
may  be  generated  for  testing  the  response  of  the  ES . 

Systems  are  often  tested  for  scenarios  that  may  rarely,  if  ever,  occur.  Typical 
operation  of  the  system  under  normal  conditions  often  is  treated  with  less  rigor 
than  some  of  the  remotely  possible  conditions.  These  remotely  possible 
conditions,  however,  may  have  serious  consequences  when  they  do  occur.  Testing 
for  conditions  such  as  these  is  referred  to  as  disaster  testing.  This  type  of 
testing  is  also  necessary  for  testing  completeness  of  the  system. 

5. 5. 4. 6.1  Automating  Knowledge  Base  Verification 

Some  tools  are  designed  to  assist  the  developer  in  automating  the  knowledge 
acquisition  process.  Others  can  keep  the  knowledge  engineer  in  charge  of  the 
knowledge  transfer  process.  As  ESs  become  more  commonplace  and  take  on  critical 
tasks,  the  need  for  tools  to  assist  in  the  validation  process  increases.  Methods 
to  automate  the  validation  process  can  provide  many  benefits.  Tools  can  shorten 
the  verification  process,  eliminate  bias,  and  catch  problems  that  may  otherwise 
be  overlooked.  Following  are  the  types  of  problems  that  may  be  found  using 
automated  tools: 

■  Syntactic  errors 

■  Unused  rules,  facts,  and  questions 
•  Incorrectly  used  legal  values 
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Redundant  constructs 


■  Rules  that  use  illegal  values,  incorrect  external  declarations  or 
references,  and  multiple  methods  for  obtaining  expression  values 

Jafar  and  Bahill  (1993)  describe  a  tool  called  Validator.  This  tool  provides  an 
interactive  environment  that  is  used  to  identify  certain  types  of  errors  that  may 
exist  in  knowledge-based  systems.  Syntax  errors,  misspelled  words,  values  out 
of  range,  and  unused  values  and  rules  are  some  of  the  errors  detected  by 
Validator.  It  has  been  exercised  on  a  number  of  ES  knowledge  bases  produced  by 
university  students,  in  addition  to  demonstration  system  knowledge  bases  from 
commercial  software  houses. 

5.5.5  Supportability  Issues  for  Expert  Systems 

In  a  systems  engineering  environment,  supportability  issues  are  not  considered 
after  a  product  is  fielded.  They  are  considered  at  the  requirements  level  and 
influence  the  specification,  design,  and  testing. 

Following  are  several  techniques  used  to  enhance  supportability  of  ES s  (Carlton 
1987): 

■  Keeping  the  inference  engine  separate  from  the  knowledge  base  -  Allows  the 
knowledge  base  to  be  maintained  without  inference  engine  changes,  allowing 
ease  of  use  and  flexibility. 

■  Representing  knowledge  uniformly  -  The  higher  the  number  of  structures 
used  to  represent  knowledge,  the  greater  will  be  the  effort  when  updates 
are  required.  It  could  be  difficult  to  maintain  a  single  mechanism  since 
the  problem  type  may  dictate  the  most  efficient  representation. 

•  Avoiding  complexity  in  the  inference  engine  -  For  cases  where  the 

inference  engine  is  developed  by  the  user,  a  well— designed  and  simplified 
engine  facilitates  the  generation  of  explanations. 

■  Utilizing  redundancy  -  When  developing  the  knowledge  base,  the  use  of 
multiple  knowledge  sources  is  recommended  so  that  confidence  in  system 
performance  is  increased. 

Another  supportability  issue  focuses  on  the  development  environment  used.  If  an 
ES  shell  is  used,  development  can  be  faster  and  more  reliable.  Additionally, 
maintenance  can  be  performed  on  this  type  of  system  by  nonprogrammers.  If  an  HOL 
is  used,  the  developer  has  greater  flexibility  with  knowledge  representation  and 
inferencing  schemes.  Additionally,  if  an  HOL  is  used,  other  considerations 
should  be  weighted,  such  as  ease  of  use,  expressiveness,  and  flexibility  of  the 
HOL,  since  these  factors  influence  supportability. 

5.5.6  Configuration  Management  Issues  for  Expert  Systems 

Configuration  Management  (CM)  is  a  process  or  discipline  that  manages  and 
controls  the  modification  of  hardware  and  software  components  of  a  system.  It 
defines  functional  and  physical  component  character istics  and  records  and  reports 
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changes  in  the  status  of  these  components.  It  should  be  applied  rigorously  to 
large-scale  software  and  hardware  development  efforts.  It  has  classically  been 
applied  to  procedural  software. 

Knowledge  can  be  represented  both  procedurally  and  declaratively .  Procedural 
solutions  are  derived  after  a  sequence  of  instructions  is  executed.  An  inference 
engine  is  an  example  of  procedural  knowledge.  Conventional  programs  are  totally 
procedural,  while  knowledge  bases  may  contain  a  mix  of  procedural  and  declarative 
knowledge.  Declarative  knowledge  consists  of  facts  asserted  to  be  true.  An 
inference  scheme  is  also  associated  with  these  facts  (Carlton  1987) . 

CM  techniques  applied  to  procedural  software  are  understood  and  can  be  applied 
easily.  Since  the  inference  engine  is  procedural,  CM  for  it  is  well  defined. 
Changes  to  the  knowledge  base  have  no  influence  on  the  inference  engine . 
According  to  Carlton  (1987),  conventional  CM  for  the  knowledge  base  presents  a 
problem.  He  states: 

While  conventional  configuration  management  procedures  can  be 
applied  to  the  knowledge  base,  this  will  put  unnecessary  constraints 
on  the  flexibility  of  the  knowledge-based  system  by  limiting  the 
ability  of  the  user  to  make  changes  to  the  knowledge  base  to  suit 
local  conditions. 

Changes  to  the  knowledge  base  may  become  necessary  when  the  ES  operating 
environment  changes.  Local  conditions  are  considered  when  information  contained 
in  the  knowledge  base  is  tailored  to  suit  each  operating  environment.  In  this 
case,  rapid  changes  to  the  knowledge  base  are  required  and  the  conventional  CM 
process  will  be  burdensome. 

A  solution  to  this  problem  is  suggested.  If  the  knowledge-based  system  can  track 
its  own  configuration,  much  of  the  CM  burden  can  be  alleviated.  This  can  be 
accomplished  by  having  the  system  track  changes  and  note  them  in  a  configuration 
data  file.  This  file  can  be  transmitted  to  the  CM  facility  periodically.  This 
file  is  then  subject  to  central  control  and  analysis  (Carlton  1987). 

5.5.7  Reliability  Requirements 

Metrics  can  be  valuable  sources  of  indicators  for  both  development  cost  and 
failure  intensity.  Two  common  metrics  applied  to  conventional  software  include 
complexity  and  size.  The  assumption  is  that  larger  programs  and  more  complex 
programs  will  contain  more  errors  and,  therefore,  be  less  reliable.  A  major 
difficulty  is  knowing  which  metrics  to  use  and  how  to  interpret  the  results 
(Rushby  1988) .  Measuring  reliability  is  further  complicated  due  to  the 
differences  between  knowledge-based  and  conventional  software.  Further 
information  on  software  metrics  can  be  found  in  DOT/FAA/CT— 91/1 ,  "Software 
Quality  Metrics." 

Since  ES  technology  is  still  rather  young,  there  is  a  lack  of  experimental  data 
for  these  systems.  It  also  may  be  risky  to  assume  that  the  relationships 
observed  for  conventional  software  will  apply  in  the  same  way  to  ESs.  Concerning 
this,  Rushby  (1988)  states: 
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Empirical  data  will  need  to  be  gathered  in  order  to  suggest  and 
validate  useful  relationships  among  metrics  for  AI  software.  It  is 
unlikely  that  simple  counts  of  the  number  of  statements  or  rules  in 
an  AI  system's  knowledge  base  will  yield  useful  information 
regarding  its  competence. 

5.5.8  Testability  Issues  for  Expert  Systems 


5. 5. 8.1  Testing  Techniques 

With  conventional  software,  coverage  techniques  exist  for  testing.  They  include 
branch,  path,  and  condition  coverage.  Critical  paths  can  be  examined  and  traced 
through  the  software.  The  same  is  not  true  for  knowledge-based  software,  since 
no  critical  paths  exist  to  trace. 

There  are  a  large  number  of  possible  combinations  and  permutations  of  knowledge. 
This  necessitates  a  change  of  testing  methods  for  knowledge  bases.  Additionally, 
the  number  of  test  cases  available  to  test  the  operation  and  performance  of  the 
ES  will  influence  the  testing  coverage  and  the  user's  confidence  in  the  system. 


5. 5. 8. 2  Validity  of  Input  Data 

For  conventional  software,  input  data  are  tested  for  validity  by  verifying  that 
they  are  within  acceptable  bounds  as  defined  for  the  system.  Methods  for 
checking  the  validity  of  largely  symbolic  data  need  to  be  examined  and  developed 
for  knowledge— based  systems. 

5.5. 8. 3  Testing  Level  for  Changes  to  the  Knowledge  Base 


A  change  made  to  the  knowledge  base  of  an  ES  used  in  a 
testing.  The  level  of  testing  required  is  unclear, 
knowledge  bases  may  mitigate  some  of  the  difficulties 
changes  (Carlton  1987)  . 


critical  system  requires 
Working  with  partitioned 
encountered  when  testing 
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6.  HUMAN  FACTORS  AND  ARTIFICIAL  INTELLIGENCE 


The  amount  of  data  that  the  flight  crew  must  absorb  has  increased  due  to  the 
expanding  complexity  and  number  of  avionic  systems  in  the  cockpit.  Reducing 
pilot  and  information  overload  can  be  achieved  using  AI .  As  with  any  technology, 
the  final  system  interface  (i.e.,  man-machine  interface)  needs  to  be  an  integral 
part  of  the  design  and  development  cycle. 

Human  factors  concerns  cover  all  aspects  of  technology,  from  design  through 
implementation.  To  field  automated  intelligent  systems  and  pilot  assistants  that 
add  to  the  safety  of  flight,  human  factors  technology  should  be  applied  to 
designs  from  the  beginning.  This  will  ensure  that  potential  problems  are 
identified  and  corrected  before  they  have  significant  impact  on  system 
development . 

6.1  Expert  System  Development  Stages 

There  are  four  critical  stages  of  development  for  ESs  and  their  human  factors- 
related  concerns,  as  identified  by  Wickens  (1992): 

■  Knowledge  Acquisition  -  For  complex  ESs,  the  process  of  extracting 
knowledge  from  experts,  and  implementing  that  knowledge  in  the  form  of  a 
rule  base,  can  be  a  considerable  challenge.  Information  supplied  by  the 
expert  is  subject  to  bias  for  which  "debiasing"  techniques  may  need  to  be 
applied.  Additionally,  not  all  expert  knowledge  can  be  verbalized. 
Methods  other  than  verbalization  may  need  to  be  explored. 

■  Knowledge  Representation  -  How  knowledge  is  organized  is  a  concern.  Is  it 
understandable  and  can  it  be  retrieved  easily  by  users?  Also, 
consideration  is  necessary  for  tailoring  the  stored  knowledge  to  the 
capability  level  of  the  user. 

■  Knowledge  Utilization  -  The  design  of  the  computer  interface  must  consider 
sound  human  factors  design  techniques.  This  includes  displays  and 
controls,  as  well  as  the  vocabulary  used  to  communicate  with  the  user. 
Another  factor  that  needs  to  be  addressed  is  how  the  confidence  level  of 
the  ES's  offered  advice  (which  is  a  variable)  is  communicated  to  the  user. 

-  Knowledge  Maintenance  -  As  is  typical  with  any  computer  system,  its  data 

occasionally  requires  revision.  Knowledge  bases  of  ESs  also  require 
maintenance,  either  with  new  information  being  added  or  older  knowledge 
being  modified.  How  this  is  done,  and  when  it  is  done,  are  concerns  that 
certification  specialists  need  to  address. 
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6.2  National  Plan  and  Artificial  Intelligence 

A  valuable  resource  for  identifying  human  factors  issues  and  related  safety 
concerns  is  the  FAA's  National  Plan  for  Aviation  Human  Factors.  This  Plan 
represents  the  first  step  of  an  intensive  effort  to  coordinate  human  factors- 
related  research  in  aviation  among  government  agencies,  such  as  the  FAA,  NASA, 
and  DOD . 

In  the  Plan,  a  number  of  issues  are  raised  that  focus  on  safety  concerns  for 
intelligent  cockpit  devices.  One  such  concern  is  how  pilots  will  react  to 
probabilistic  AI.  The  Plan  states: 

Automated  flight  deck  systems  will  soon  incorporate  artificial 
intelligence  with  the  capability  to  give  pilots  information  or 
advice  about  complex  matters  with  an  associated  probability  that  it 
is  correct.  Before  such  probabilistic  AI  systems  come  into 
extensive  use  in  advanced  technology  aircraft,  we  need  to  know  more 
about  how  crews  will  react  to  them,  how  to  design  them  for  optimum 
use,  and  how  to  train  crews  to  interpret  and  use  the  probabilistic 
information. 

In  addition,  other  concerns,  such  as  those  listed  below,  are  identified  and 
expressed  in  the  Plan: 

■  Intelligent  automated  systems  should  not  be  able  to  move  the  aircraft  out 
of  the  safe  operating  envelope. 

•  The  test  and  validation  methodology  for  intelligent  automated  systems  is 
still  in  its  infancy  and  requires  research  and  definition. 

■  The  reaction  of  the  flight  crew  to  the  type  of  information  presented  by  an 
AI  system  requires  investigation. 

6.3  Keeping  the  Human  as  a  Factor 

One  of  the  human  factors  problems  identified  for  automated  systems  is  the  user's 
overconfidence  in  the  decision  making  process.  According  to  Wickens  (1993),  one 
of  the  methods  proposed  to: 

deal  with  bias,  one  that  is  emerging  in  the  commercial  flight  deck 
and  is  already  used  in  the  military  flight  deck...  [is  the  use  of 
expert  system  technology] .  Expert  systems  can,  at  least  according 
to  some  scientists,  replace  some  of  the  pilot  decision  making 
necessary  in  the  cockpit,  or  at  least  can  recommend  judgements  to 
the  pilot ... 

Automated  decision  aiding  has  been  studied  for  its  ability  to  reduce  or  eliminate 
bias  from  decision  making.  There  is  some  concern  that  these  aids  may  serve  to 
worsen,  and  not  improve,  decision  performance  (Wiener  and  Nagel  1988).  In  many 
of  the  cases  where  poor  performance  was  noted,  the  human  was  used  to  gather  data 
and  implement  decisions  of  the  computer.  In  some  cases,  the  combination  led  to 
worse  performance  than  either  the  machine  or  human  acting  alone. 
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A  method  of  improving  the  overall  performance  and  interaction  is  shown  in  figure 
6.1—1.  This  method  takes  into  account  the  capabilities  and  strengths  of  the 
human  and  the  machine.  All  of  the  possible  solutions  are  generated  by  the 
machine.  A  more  active  role  for  the  human  is  maintained  using  this  method,  and, 
hence,  the  human  remains  in  the  loop  in  a  key  role;  not  merely  as  a  physical 
actuator  for  control  input  devices. 


FIGURE  6.1-1.  IMPROVED  HUMAN  PERFORMANCE  GENERATOR 
(Wiener  and  Nagel  1988) 


Keeping  the  pilot  in  the  loop  is  a  concern,  whether  due  to  use  of  AI  or  due  to 
use  of  any  cockpit  automation  system.  Reliance  on  yet  another  system  may  lead 
to  further  complacency  and  inattentiveness.  Failure  of  an  automated  system 
creates  increased  crew  workload,  often  at  a  time  when  this  additional  workload 
is  unwelcome. 

Any  system,  whether  analog  or  digital,  is  prone  to  failure.  A  number  of  factors, 
including  system  complexity  and  unforeseen  circumstances,  prevent  avionic  systems 
from  operating  error  free  over  their  life  cycle.  The  unintentional  changing  of 
a  single  bit  of  a  digital  system,  whether  by  a  software  or  hardware  design  error 
or  externally  induced,  can  produce  significant  undesirable  consequences.  While 
it  may  be  possible  for  the  system  to  monitor  itself  and  flag  most  of  these 
errors,  not  all  problems  are  identified  and  announced  to  the  system  operator. 
Other  systems  may  be  used  to  monitor  system  health  and  reduce  the  probability  of 
an  undetected  failure.  Therefore,  the  role  of  the  human  as  a  system  monitor 
should  remain,  regardless  of  the  level  of  automation. 
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6.4  Automation  and  Other  Human  Factors  Concerns 

Other  factors  need  to  be  examined,  in  addition  to  the  problem  of  keeping  the 

pilot  in  the  loop.  Human  factors  concerns  over  automation  systems  reflect  some 

of  the  same  concerns  presented  by  AI  systems.  Some  of  these  concerns  are 

identified  by  Gabriel  (1993)  and  consist  of  the  following: 

■  Loss  of  Situation  Awareness  -  Monitoring  an  automated  system  that  is 
reliable  is  a  boring  task.  The  crew  becomes  distracted  easily  and  diverts 
attention  elsewhere.  When  this  happens,  awareness  of  the  current 
situation  is  diminished. 

■  Loss  of  Proficiency  -  Competence  in  a  skill  requires  practice.  How  to 
retain  skills  that  are  replaced  or  diminished  by  an  automated  system  is  a 
human  factors  issue. 

■  Reduced  Job  Satisfaction  -  Reduced  job  satisfaction  can  occur  since  the 
crew  may  no  longer  feel  that  their  skills  are  important. 

■  Overconfidence  in  the  System  -  Overconfidence  in  the  system  is  a  negative 
effect  of  automation.  If  the  system  malfunctions,  the  crew  may  not  be 
prepared  to  handle  the  consequences. 

■  Intimidation  by  Automation  and/or  Complacency  -  A  crew  lacking  experience 
or  being  overconfident  may  be  reluctant  to  take  control  when  the  automated 
system  does  not  perform  well.  In  addition,  an  automated  system  may  be 
designed  in  a  way  that  does  not  communicate  everything  that  the  crew 
should  know.  This  reluctance  and  uncertainty  may  reduce  the  ability  of 
the  crew  to  fulfill  its  responsibility. 

■  Increased  Training  Requirements  -  System  complexity  requires  increased 
training.  Part  of  the  required  training  is  to  handle  failure  modes. 
Reprogramming  can  also  be  complex.  Maintaining  proficiency  is  necessary 
and,  therefore,  increased  training  is  required. 

■  Inability  of  the  Crew  to  Exercise  Authority  -  This  results  when  the  crew 
is  further  removed  from  the  decision  making  process  by  factors  such  as 
intimidation  and  the  envelope  protection  features  of  the  system. 

■  Design  Induced  Error  -  One  of  the  goals  of  automation  is  to  reduce  human 
error.  A  concern  is  that  while  the  frequency  of  errors  is  decreased,  the 
consequence  of  the  errors  that  do  occur  is  much  greater  due  to  the  control 
exerted  by  the  automated  system.  Concerning  this,  Nigel  (in  Wiener  and 
Nigel  1988)  states: 

As  aircraft  become  more  highly  automated,  and  the  manual 
control  skills  of  the  pilot  are  displaced  by  aircraft  systems 
(autopilots)  which  perform  the  general  guidance  and  control 
functions  associated  with  management  of  the  flight  path, 
discrete  actions...  seem  to  be  assuming  increasing  importance 
in  the  causation  of  incidents  and  accidents. 
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7. 


CONCLUSION 


AI  technology  can  provide  users  with  many  benefits  in  a  number  of  applications. 
However,  there  are  limitations  as  to  what  can  be  performed  with  an  Al-based 
system.  It  will  never  be  able  to  replace  genuine  intelligence.  AI  deals  with 
automating  procedures  that  are  already  known.  If  little  is  known  about  a 
procedure,  it  is  better  to  research  the  procedure  than  to  attempt  development 
based  on  vague  specifications. 

With  currently  available  technology,  ESs  perform  better  as  assistants  or  advisors 
than  as  primary  decision  makers.  Humans  will  always  have  the  advantage  over  ESs 
in  that  they  have  the  power  of  human  sensory  pattern  recognition  and  flexibility. 
AI  systems  will  not  be  capable  of  replacing  humans  in  most  applications  and  will 
be  used  mainly  to  augment  the  capabilities  of  the  user. 

Another  issue  that  needs  to  be  addressed  is  the  proper  application  for  an  AI- 
based  system.  AI  technology  is  not  efficient  at  solving  all  types  of  problems. 
Intense  number  manipulation  and  linear  problems  would  be  better  performed  using 
conventional  methods.  There  are  certain  types  of  problems  that  naturally  lend 
themselves  to  being  solved  using  AI  techniques. 

Human  experts  often  are  in  short  supply.  ESs  are  useful  because  the  knowledge 
of  experts  can  be  incorporated  into  knowledge  bases,  allowing  users  who  are  not 
experts  to  benefit  from  the  expert's  knowledge.  NN  systems  are  helpful  for 
applications  such  as  pattern  recognition.  Fuzzy  logic  systems  are  useful  for 
systems  that  normally  require  human  intuition,  are  difficult  to  control  with 
conventional  techniques,  or  are  difficult  to  model. 

While  many  benefits  can  be  gained  from  the  use  of  Al-based  technology,  a  number 
of  issues  need  to  be  addressed  before  such  systems  are  fielded  in  critical 
applications  of  airborne  avionics.  This  section  summarizes  and  highlights  some 
key  issues  concerning  certification  of  Al-based  technology. 

7.1  Learning  Systems 

One  of  the  certification  concerns  mentioned  in  the  National  Plan  for  Aviation 
Human  Factors  is  that  airborne  software  not  be  allowed  to  remove  the  aircraft 
from  the  safe  operating  envelope.  The  capability  of  software  to  maintain  an 
aircraft  within  the  design  envelope  can  be  demonstrated  for  conventional, 
deterministic  software.  However,  this  would  be  difficult  to  demonstrate  for  Al- 
based  systems  with  learning  capability.  Therefore,  learning  systems  are  unlikely 
to  appear  in  civil  aircraft  (Naser  1991) . 

7.2  Software  Level  Determination 

While  ESs  have  been  proposed  and  may  be  developed  for  military  aircraft  for  the 
purpose  of  intervening  and  assuming  control  in  life-threatening  situations,  it 
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is  unlikely  that  this  would  happen  in  the  near  future  for  civil  aircraft.  It  is 
more  likely  that  ESs  introduced  in  the  near  future  for  civil  use  will  perform 
monitoring  and  pilot  assistant  functions.  Certification  specialists  most  likely 
will  not  require  these  systems  to  undergo  the  rigorous  inspections  and  tests  to 
which  critical  systems  are  subjected.  One  may  argue  that  since  the  system 
actually  controls  nothing,  it  is  not  able  to  affect  the  performance  and  safety 
of  the  aircraft.  On  the  other  hand,  receiving  incorrect  advice  from  a  system 
that  is  normally  relied  upon  by  the  captain  and  first  officer  can  have  dire 
consequences.  Certification  authorities  will  need  to  address  these  issues  early 
in  the  development  process,  since  determination  of  the  software  criticality  level 
of  a  system  affects  inspection  and  documentation  intensity  and,  therefore, 
implementation  cost. 

7 . 3  Enhanc ing  Safety 

An  objection  may  be  raised  that  we  are  just  adding  another  layer  of  uncertainty 
on  top  of  a  system  that  is  already  plagued  with  unknown  failures.  Digital 
systems  have  unique  failure  modes  compared  to  analog  systems.  Failures  that  are 
detected  in  aircraft  operation  at  40,000  feet  are  sometimes  not  reproducible  on 
the  test  bench.  Some  digital  systems  problems  magically  disappear  when  the 
breaker  is  cycled  off  and  on  by  the  flight  crew.  Additionally,  failures  of 
digital  systems  are  not  always  detected  in  a  timely  fashion.  With  this  level  of 
uncertainty  already  existing,  would  the  addition  of  another  level  of  uncertainty 
further  degrade  safe  flying? 

A  similar  objection  can  be  raised  when  multiple  access  data  buses  or  high-speed 
parallel  backplanes  are  implemented  for  critical  systems.  Technologies  formerly 
unknown  in  avionics  are  continually  being  designed  and  implemented  and 
certification  specialists  address  these  issues  as  they  a.rise.  At  issue  is  how 
AI  and  ES  technology  are  perceived.  If  confidence  in  the  technology  is  lacking, 
then  its  application  to  any  application  is  viewed  as  a  degradation.  If  it  is 
perceived  as  a  sufficiently  mature  technology  that  excels  in  certain  applications 
(as  it  does),  then  its  application  in  cockpit  systems  is  seen  as  a  benefit. 

7.4  Hardware  and  Software  Failures 

There  are  numerous  ways  to  express  the  same  functionality  using  conventional 
software  for  system  design.  As  tools  automate  more  of  the  development  process, 
design  is  performed  using  higher  levels  of  representation. 

One  architectural  design  technique,  mentioned  in  RTCA/DO— 178B ,  for  limiting  the 
impact  of  software  errors  is  the  use  of  redundant,  dissimilar  software.  The 
degree  of  dissimilarity  and  the  advantages  gained  by  utilizing  this  technique  are 
minimized  by  the  higher  levels  of  representation  available  to  designers.  For 
ESs,  this  is  also  the  case,  since  one  of  the  attractions  of  this  technology  is 
that  knowledge  can  be  coded  at  a  high  level.  Redundancy  implies  that  the 
expert's  rules  would  have  to  be  different  for  accomplishing  the  same  ends. 
Knowledge  base  partitioning  and  system  monitoring  techniques,  along  with 
extensive,  detailed  V&V,  may  be  the  solutions  needed  for  ESs  designed  to  perform 
critical  functions . 
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The  effect  of  hardware  failures  for  Al-based  systems  also  needs  to  be  examined. 
What  effect  will  hardware  failures  have  on  the  conclusions  reached  by  an  ES?  In 
the  case  of  a  pilot-aiding  system,  will  failures  be  detectable  only  by  the  bad 
advice  given  by  the  system?  Hardware  error  detection  schemes  will  be  critical 
to  ensure  system  reliability,  as  they  are  with  any  automated  system. 

7.5  Ground-Based  Avionics? 

There  is  a  related  issue  when  considering  the  certification  of  Al-based  airborne 
software.  Some  proposed  pilot  aid  systems  rely  upon  the  availability  of  data 
link  to  receive  company-related  information  required  by  the  system.  Data  link 
is  a  two-way  digital  communication  system.  Using  data  link,  one  could  transmit 
an  aircraft's  complete  status,  environmental  data,  and  other  necessary 
information  to  a  ground-based  facility  on  a  communication  channel.  If  that 
channel  has  sufficient  bandwidth  for  a  timely  response,  the  exact  Al-based 
program  could  be  executed  at  the  ground-based  facility  with  the  results 
transmitted  back  to  the  aircraft. 

Such  a  system  would  not  be  subject  to  the  certification  requirements  for  airborne 
software,  yet  the  only  significant  difference  would  be  the  physical  location  of 
the  CPU  that  executes  the  Al-based  software.  While  such  a  scenario  may  be 
impractical  at  the  current  time,  certification  specialists  should  consider  the 
impacts  of  relying  on  this  technology  for  airborne  support,  wherever  the  data  are 
generated. 

7.6  Verification  and  Validation  Issues 

One  of  the  primary  activities  that  requires  addressing  by  developers  and 
certification  specialists  concerns  V&V  methods  for  AI  systems.  Numerous  V&V 
techniques  that  have  been  successfully  applied  to  ESs  have  been  identified  in 
this  report.  Identifying  a  set  of  tests  that  can  be  demonstrated  to  satisfy 
safety  requirements  will  be  a  challenge. 

All  parts  of  the  ES ,  such  as  the  database,  knowledge  base,  inference  engine, 
interfaces,  and  custom  software  need  to  be  subjected  to  suitable  inspection. 
Knowledge  bases  need  to  be  complete.  Missing  rules  will  produce  errors.  For 
complex  ESs,  demonstrating  that  the  knowledge  base  is  complete  may  be  difficult, 
since  the  expert  may  not  even  be  aware  of  what  is  done  to  solve  a  problem.  Also, 
it  is  impossible  to  guarantee  that  an  ES  contains  all  of  the  expert's  knowledge. 

The  knowledge  base  also  needs  to  be  error  free.  Many  of  the  techniques  used  with 
conventional  software  may  be  used  to  demonstrate  that  the  system  will  not  produce 
incorrect  results.  Also  crucial  to  the  knowledge  base  is  maintaining  data 
integrity.  Maintaining  an  accurate,  up-to-date,  database  is  essential  for 
product  integrity  throughout  the  product  life  cycle.  Knowledge  acquisition, 
representation,  and  data  transformation  techniques  should  be  tested. 

As  with  conventional  software,  key  to  the  certification  process  for  ESs  will  be 
the  faithful  application  of  a  thorough  V&V  process ,  applied  uniformly  and 
starting  with  the  product  specification.  Life  cycle  factors  such  as 
supportability ,  maintainability,  and  CM  need  to  be  considered  and  tailored  for 
ESs  as  necessary. 
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7.7  Tool  Qualification 


Tools  at  all  levels  of  the  development  process  can  assist  in  achieving  cost, 
safety,  and  other  goals.  Tools  enhance  the  development  process  by  reducing 
development  time  and  assisting  in  the  elimination  of  human  design  error.  Tools 
to  automate  knowledge  base  verification  could  provide  substantial  benefits  when 
addressing  knowledge  base  integrity  issues.  Standardization  of  knowledge  base 
representation  may  be  necessary  to  implement  the  automation  process.  Also,  tool 
qualification  issues  require  addressing  since  a  new  set  of  tools  focusing  on  this 
field  will  require  validation. 

7.8  Design  Guidance 

ESs  should  be  scrutinized  using  conventional  V&V  techniques  where  possible. 
RTCA/DO-178B  needs  to  be  examined  to  identify  details  of  the  processes  that  need 
to  be  modified  to  accommodate  differences  in  Al-based  and  conventional 
development.  Further  effort  is  needed  to  develop  relevant  design  guidance  for 
Al-based  systems. 

7.9  Human  Factors  Issues  for  Expert  Systems 

Developing  human-centered  automation  and  designing  advanced  technology  that  will 
capitalize  on  the  relative  strengths  of  humans  and  machines  are  key  to  the 
success  and  usefulness  of  AI .  Also,  applying  certification  criteria  to  advanced 
technology  systems,  as  part  of  the  development  process,  will  provide  significant 
advantages  for  the  testing  phase. 

The  use  of  AI  on  the  flightdeck  brings  up  many  issues  relating  to  automation  that 
need  to  be  dealt  with.  Human  factors  specialists  will  need  to  address  areas  such 
as  possible  loss  of  situation  awareness  and  proficiency,  in  addition  to 
overconfidence  in  the  system  or  intimidation  by  the  system.  The  overall 
significance  of  incorporating  probabilistic  systems  in  the  cockpit  should  be 
addressed  as  well. 

Wickens  (1993)  states  that  too  little  is  known  about  the  way  pilots  make 
decisions  and,  therefore,  ESs  should  not  be  entrusted  with  decision 
recommendations.  While  this  is  certainly  a  concern  and  has  been  the  focus  of 
much  research  for  the  PA  and  other  studies,  the  many  benefits  of  using  Al-based 
technology  beg  to  be  investigated.  At  issue  is  not  the  complete  understanding 
of  the  human  thought  process,  but  using  a  logical,  consistent,  unbiased  decision 
tool  (inference  engine)  to  make  conclusions  based  on  available  data.  Simple 
systems,  such  as  diverters  and  diagnostic  aids  based  on  ESs  present  logical 
approaches  to  solving  complex  problems  in  an  accurate  and  timely  fashion. 

Al-based  systems  for  commercial  aircraft  are  being  researched  and  tested.  These 
systems  can  offer  distinct  advantages  over  conventional  software  systems. 
Ultimately,  such  systems  can  offer  economic  advantages  and  contribute  to  flight 
safety.  Al-based  pilot  aiding  systems  have  the  potential  to  contribute 
meaningfully  to  aviation.  A  solution  that  matches  the  technology  with  the 
problem  to  be  solved,  using  a  systems  engineering  approach,  will  be  a  solid  start 
for  developers  of  AI— based  avionics . 
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GLOSSARY 


A  PRIORI .  Pertaining  to  deductive  reasoning  from  assumed  axioms  or  supposedly 
self-evident  principles,  without  reference  to  experience. 

ADAPTIVE  FUZZY  SYSTEMS.  Fuzzy  controllers  with  the  ability  to  learn  and  explain 
their  reasoning. 

ALGORITHM .  A  set  of  well-defined  rules  for  the  solution  of  a  problem  in  a  finite 
number  of  steps. 

ANALOG .  Pertaining  to  devices,  data,  circuits,  or  systems  that  operate  with 
variables  that  are  presented  by  continuously  measured  voltages  or  other 
quantities . 

ARC.  The  part  of  a  semantic  network  that  connects  one  object  to  another. 

ARTIFICIAL  INTELLIGENCE.  The  subfield  of  computer  science  concerned  with 
emulating  human  intelligence  by  use  of  software  and  hardware  techniques. 

ASSISTANT.  An  Expert  System  that  performs  a  technically  limited  subset  of  an 
expert's  task. 

ASSOCIATIVE  MEMORY  NETWORK.  A  network  where  different  input  patterns,  if 
sufficiently  similar,  become  associated  with  one  another  (trigger  the  same 
response) . 

ASYNCHRONOUS .  Operating  at  a  speed  determined  by  the  circuit  functions  rather 
than  by  timing  signals. 

ATTRACTOR .  The  geometrical  pattern  toward  which  the  trajectory  of  a  dynamical 
system,  represented  by  a  curve  in  phase  space,  converges  in  the  course  of  time. 

AXON.  The  pathway  that  carries  the  output  of  a  biological  neuron. 

BACK  PROPAGATION.  An  algorithm  used  to  adjust  weights  connecting  neurons  in 
successive  layers  of  multi-layer  networks.  Back  propagation  learns  by  example 
and  repetition. 

BACKWARD  CHAINING.  A  method  of  problem  solving  that  works  backward  from  a  known 
conclusion  in  an  attempt  to  find  a  path  of  reasoning  in  order  to  justify  the 
conclusion. 

BASIN  OF  ATTRACTION.  The  collection  of  all  possible  initial  conditions  of  a 
dynamical  system  for  which  the  trajectories  representing  that  system  in  phase 
space  will  converge  to  a  particular  attractor. 
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BINARY.  Composed  of  or  characterized  by  two  parts  or  elements. 


BLACK  BOX.  A  component  having  known  input  and  output,  that  can  be  readily 
inserted  into  or  removed  from  a  specific  place  in  a  larger  system  without 
knowledge  of  the  component's  detailed  internal  structure. 

BLACKBOARD .  The  controlling  agent  in  a  blackboard  system  that  tracks  activity 
between  the  knowledge  sources. 

BLACKBOARD  SYSTEM.  An  Expert  System  that  uses  multiple  knowledge  sources  that 
share  data. 

RODT.F.AN  T.OCTC.  The  basic  mathematics  needed  to  study  the  logic  design  of  digital 
systems.  Boolean  logic  consists  of  two  values  and  three  basic  operators. 

BREADTH  FIRST.  The  method  of  searching  for  solutions  by  considering  all  possible 
subgoals  on  one  level  before  proceeding  to  the  next  level. 

CERTAINTY  FACTOR.  A  value  that  represents  the  level  of  belief  associated  with 
a  fact  or  a  rule . 

CERTIFICATION.  The  process  of  obtaining  FAA  approval  for  the  design, 
manufacture,  and/or  sale  of  aircraft  and  associated  systems,  subsystems,  and 
parts . 

CLOSED-LOOP.  A  family  of  automatic  control  units  linked  together  with  a  process 
to  form  an  endless  chain;  the  effects  of  control  action  are  constantly  measured 
so  that  if  the  controlled  quantity  departs  from  the  norm,  the  control  units  act 
to  bring  it  back. 

CLUSTERING .  A  technique  to  group  similar  objects  together  under  the  same  label. 

CODIFYING.  A  method  of  representing  knowledge  or  data  so  they  can  be  stored  in 
a  knowledge  base  or  database  for  access  by  a  computer. 

COLLEAGUE.  An  Expert  System  that  performs  a  significant  subset  of  an  expert's 
task. 

CONNECTION  WEIGHT.  A  method  of  representing  the  strength  of  the  connection 
between  nodes. 

CONVENTIONAL  PROGRAMMING.  The  use  of  standard  programming  languages,  as  opposed 
to  application  development  languages,  financial  planning  languages,  query 
languages ,  and  report  programs . 

CONVERGENCE .  The  point  when  the  outputs  of  a  Neural  Network  are  no  longer 

changing . 

CRISP  SET.  The  membership  concept  used  in  traditional  system  modelling,  where 
objects  are  either  in  or  out  of  the  set  with  no  intermediate  step. 
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DATA  DRIVEN.  Describing  the  execution  of  a  program  in  a  data  flow  system,  in 
which  an  instruction  is  carried  out  whenever  all  its  input  values  are  present. 

DECLARATIVE.  Generally,  the  knowledge  found  in  the  knowledge  base;  independent 
knowledge  that  does  not  contain  procedures  or  methods  of  handling  other 
knowledge . 

DEDUCTIVE .  Learning  by  logical  inference  or  inferring  from  available  knowledge. 

DEFUZZIFICATION .  The  process  of  translating  fuzzy,  or  non-crisp  values  into 
crisp,  clearly  defined  values. 

DEMON.  A  procedure  activated  by  changing  or  accessing  values  in  a  database. 

DENDRITE .  The  pathway  that  carries  the  input  of  a  biological  neuron. 

DEPTH  FIRST.  A  method  of  searching  for  a  solution  by  pursuing  each  branch  of  the 
search  tree  to  the  end  before  considering  another  branch. 

DOT  PRODUCT.  The  inner  product  of  vectors  (xx,  .  .  .  .xj  and  (yx . yn)  from  n- 

dimensional  euclidean  space  is  the  sum  of  s^,  as  i  ranges  from  1  to  n. 

EMPIRICAL  MODEL.  The  model  of  a  system  based  on  data  and  the  principles  of 
statistics.  Empirical  models  produce  relationships,  not  insight. 

EVENT .  A  change  to  the  blackboard  of  a  Blackboard  System. 

EXPERT .  1.  An  Expert  System  that  approaches  an  expert's  level  of  performance 

within  a  given  domain.  2.  A  person  who  has  mastered  solving  specific  types  of 
problems . 

EXPERT  SYSTEM.  A  computer  system  designed  to  simulate  the  problem  solving 
behavior  of  a  human  expert. 

EXPERT  SYSTEM  SHELL.  An  Expert  System  development  tool  and  run-time  environment 
with  a  modifiable  knowledge  base. 

FACETTE .  A  piece  of  knowledge  in  a  frame. 

FEED  FORWARD  NEURAL  NETWORK.  A  Neural  Network  where  the  only  connections  are 
from  a  neuron  in  one  layer  to  a  neuron  in  the  next  layer . 

FILTER .  A  transmission  network  used  in  electrical  systems  for  the  selective 
enhancement  of  a  given  class  of  input  signals. 

FORWARD  CHAINING.  A  method  of  solving  problems  by  beginning  with  certain  data 
and  moving  down  the  inference  chain  until  a  solution  is  reached. 

FRAME.  A  way  of  representing  Expert  System  knowledge  that  consists  of  a  set  of 
slots  that  contain  data. 

FRAME  LABEL.  A  unique  frame  identification. 
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FUZZIFICATION.  The  process  of  converting  crisp  inputs  into  fuzzy  values. 


FUZZY  CONTROL  VARIABLE.  A  parameter  whose  value  determines  the  action  taken  by 
fuzzy  rules. 

FUZZY  EXPERT  SYSTEM.  An  Expert  System  that  uses  fuzzy  logic  techniques  to  solve 
problems . 

FUZZY  LOGIC.  The  theory  of  representing  vague  or  imprecise  concepts  to  model 
inherent  conditions . 

FUZZY  SET.  An  extension  of  the  concept  of  a  set,  in  which  the  characteristic 
function  which  determines  membership  of  an  object  in  the  set  can  take  on  any 
value  between  0  and  1 . 

FUZZY  TERMS .  Words  used  for  descriptions  that  may  not  be  precise  in  determining 
set  memberships . 

GRACEFUL  DEGRADATION.  A  programming  technique  to  prevent  catastrophic  system 
failure  by  allowing  the  machine  to  operate,  though  in  a  degraded  mode,  despite 
failure  or  malfunction  of  several  integral  units  or  subsystems. 

HETEROASSOCIATIVE .  A  Neural  Network  where  output  patterns  are  distinct  from 
input  patterns . 

HEURISTIC.  Any  rule  of  thumb,  strategy,  or  technique  used  to  limit  the  time 
required  to  search  for  solutions  in  large  problem  spaces. 

HEURISTIC  REASONING.  Using  an  expert's  rules  of  thumb,  in  the  absence  of  precise 
control  mechanisms,  to  reduce  the  space  that  must  be  searched  for  a  solution. 

HIDDEN  LAYER.  The  middle  layer  in  a  Neural  Network  which  takes  outputs  from  the 
input  layer,  processes  them,  and  passes  them  to  the  output  layer. 

INDUCTIVE .  Learning  by  information  repetition. 

INFERENCE  CHAIN.  The  path  of  reasoning  that  the  inference  engine  follows  to  find 
a  solution  to  the  problem. 

INFERENCE  ENGINE.  The  part  of  an  Artificial  Intelligence  system  that  uses 
knowledge  in  the  knowledge  base  and  acquired  knowledge  about  the  problem  to  form 
an  expert  solution. 

INFERENCE  MECHANISM.  Controls  the  use  of  the  knowledge  base  and  databases  when 
solving  a  problem. 

INPUT  LAYER.  The  first  layer  of  neurons  in  a  Neural  Network.  The  input  layer 
accepts  the  input  values  and  passes  them  to  the  hidden  layer.  The  input  layer 
does  not  process  data. 

KNOUT  .EDGE  ACQUISITION.  The  process  of  gathering  the  required  information  from 
various  sources  by  a  knowledge  engineer . 
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KNOWLEDGE  BASE.  A  form  of  coded  knowledge  about  a  specific  domain. 


KNOWLEDGE-BASED  SYSTEM.  A  computer  system  whose  usefulness  derives  primarily 
from  a  database  containing  human  knowledge  in  a  computerized  format. 

KNOWLEDGE  ENGINEER.  The  person  responsible  for  extracting,  organizing,  and 
encoding  the  knowledge  related  to  the  problem,  and  importing  it  into  a  knowledge 
base  or  database . 

LABEL.  A  data  item  that  serves  to  identify  a  data  record,  or  a  symbolic  name 
used  in  a  program  to  mark  the  location  of  a  particular  instruction  or  routine. 

LAYER.  A  row  of  neurons  in  a  Neural  Network;  there  are  usually  three  layers  in 
a  network. 

LOGICAL  SUM.  The  final  unified  result  of  the  rule  processes  of  a  fuzzy  system. 

MACHINE  T. EARNING  The  process  or  technique  by  which  a  device  modifies  its  own 

behavior  as  the  result  of  its  past  experience  and  performance. 

META-KNOWLEDGE .  Knowledge  that  reveals  details  about  the  system  knowledge. 

MODEL.  A  mathematical  or  physical  system,  obeying  certain  specified  conditions, 
whose  behavior  is  used  to  understand  a  physical,  biological,  or  social  system  to 
which  it  is  analogous  in  some  way. 

NEURAL  NETWORK.  A  system  modelled  after  the  brain,  used  to  solve  problems  by  a 
mapping  of  input  data  to  output  data. 

NEURO- FUZZY .  Integrating  a  Neural  Network  and  fuzzy  logic  to  solve  problems. 

NEURON .  The  computational  element  in  a  Neural  Network.  A  neuron  computes  the 
weighted  sum  of  the  inputs  from  other  neurons  and  produces  an  output. 

NODE.  1.  Representation  of  an  object  that  is  related  to  other  objects  via 
connection  weights.  2.  The  part  of  a  Neural  Network  that  calculates  and 
processes  information. 

NOISE.  Meaningless  or  erroneous  bits  that  must  be  ignored  or  removed  from  a 
signal,  especially  in  communication  channels. 

NON  REAL-TIME  LEARNING.  Learning  done  in  a  Neural  Network  before  attempting  to 
solve  application  problems . 

NONLINEARITY .  A  system  in  which  the  outputs  do  not  correspond  to  the  inputs  in 
a  direct  or  inversely  proportional  relationship. 

OBJECT-ORIENTED .  A  representation  form  for  knowledge  in  which  all  properties  of 
an  object  are  associated  by  the  outgoing  and  incoming  arcs  at  its  node;  the 
representation  is  geared  towards  manipulating  objects  as  independent  pieces  of 
knowledge. 
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OPPORTUNISTIC  REASONING.  The  process  of  solving  problems  in  a  way  that  is  not 
uniform  or  predictable.  Opportunistic  reasoning  attempts  to  solve  the  problem 
in  the  best  possible  way  for  each  individual  situation.  Rules  fire  when  they  are 
appropriate,  without  a  priori  ordering. 

OUTPUT  LAYER.  The  layer  of  neurons  in  a  Neural  Network  that  takes  the  outputs 
from  the  hidden  layer,  processes  them,  and  then  produces  the  output  of  the 
network. 

PARAT.T.F.L  PROCESSING.  Performing  many  different  calculations  simultaneously  to 
reach  one  conclusion  or  solution. 

PREDICATE  CALCULUS .  A  formal  language  of  classical  logic  that  uses  functions  and 
predicates  to  describe  relations  between  individual  entities . 

PROBABILITY.  A  theory  dealing  with  the  uncertainty  that  results  from  random 
behavior.  Probability  is  defined  over  the  numeric  range  of  0  to  1. 

PROCESSING  ELEMENT.  The  part  of  the  Neural  Network  where  the  computations  are 
performed. 

PRODUCTION  RULES.  A  common  technique  for  representing  procedural  knowledge  in 
an  Artificial  Intelligence  system. 

REAL-TIME  LEARNING.  Learning  done  in  a  Neural  Network  while  solving  an 
application  problem. 

RECURSION.  A  technique  in  which  an  apparently  circular  process  is  used  to 
perform  an  iterative  process. 

RULE-BASED.  An  Artificial  Intelligence  program  where  knowledge  is  represented 
as  rules. 

RULES .  A  method  of  representing  knowledge  in  the  form  of  IF  THEN  statements. 

SCHEDULER.  A  part  of  an  inference  engine  that  determines  which  knowledge  source 
should  be  activated,  and  in  what  order. 

SEARCH  TREE.  The  branches  of  possible  solutions  to  a  problem  that  start  with 
initial  information  and  spread  out  following  different  paths . 

SELF-SUPERVISED .  A  method  of  training  a  Neural  Network  without  the  use  of  an 
external  monitor.  A  feedback  device  that  detects  errors  and  adjusts  the 
connection  weights  accordingly  is  used. 

SEMANTIC  NETWORK.  A  method  of  representing  knowledge  using  nodes  and  arcs. 

SLOTS .  Subdivisions  making  up  the  frame  that  may  contain  data,  procedures,  or 
pointers  to  other  frames. 

SPURIOUS  STATE.  A  point  in  a  Neural  Network  that  acts  as  an  attractor,  but  is 
not  one  of  the  stored  patterns. 
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STABILITY.  The  property  of  a  system  which  remains  under  control  and  responds  in 
a  reasonable  manner  to  an  applied  input. 

SUPERVISED  T.F.ARNTNG .  A  method  of  training  a  Neural  Network  in  which  an  external 
supervisor  monitors  the  activities,  and  learning  occurs  on  the  basis  of  direct 
comparison  of  the  output  of  the  network  with  known  correct  answers. 

SYMBOLIC  PROCESSING.  A  method  of  processing  knowledge  where  the  relationships 
among  the  knowledge  are  stored  using  symbolic  representations;  thus,  the  system 
can  deal  freely  with  objects  and  not  be  concerned  with  their  composition. 

SYNAPSES .  Pathways  in  a  biological  neuron  that  transmit  pulses  from  one  neuron 
to  another. 

SYNCHRONOUS .  In  step,  or  in  phase,  as  applied  to  two  or  more  circuits,  devices, 
or  machines. 

TRADITIONAL  PROGRAMMING.  The  use  of  standard  programming  languages,  as  opposed 
to  application  development  languages,  financial  planning  languages,  query 
languages ,  and  report  programs . 

TRAINING .  A  change  in  connection  weight  values  of  a  Neural  Network  that  results 
in  capturing  information  that  can  be  recalled  later. 

TRANSFER  FUNCTION.  The  mathematical  relationship  between  the  output  of  a  control 
system  and  its  input:  for  a  linear  system,  it  is  the  Laplace  transform  of  the 
output  divided  by  the  Laplace  transform  of  the  input  under  conditions  of  zero 
initial-energy  storage. 

TRANSPARENCY.  A  characteristic  of  knowledge  in  an  Expert  System  referring  to  its 
independence  from  other  knowledge.  There  is  no  processing  information  in  the 
transparent  knowledge . 

UNSUPERVTSF.n  T.F.ARNTNG-  A  method  of  training  a  Neural  Network,  where  no  external 
monitor  is  involved;  the  Neural  Network  organizes  itself  by  grouping  and 
generating  its  own  classification  of  inputs. 

VERY  LARGE  SCALE  INTEGRATION.  Describing  Integrated  Circuits  with  more  than  1000 
elements . 

WEIGHT  MATRIX.  The  collection  of  connection  weights  for  an  entire  Neural 
Network. 
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GLOSSARY 


g- FAULT .  {10}  A  fault  activated  by  the  baseline  program  (see  E-FAULT). 

A  PRIORI .  {20}  Pertaining  to  deductive  reasoning  from  assumed  axioms  or 

supposedly  self-evident  principles,  without  reference  to  experience. 

A-SPECIFICATION .  {9}  The  highest  level  specification  typically  produced  by  the 
contracting  organization  to  define  a  system  (see  MIL-STD-1521) . 

ABSORPTION  LOSS.  {11}  Attenuation  or  retention  of  electromagnetic  energy  passing 
through  a  material,  a  shield.  Absorption  loss  and  reflection  loss  contribute  to 
total  shielding  effectiveness  (SE) . 

ACCESS  .  {18}  The  process  of  a  transmitting  bus  user  obtaining  control  of  a  data 
bus  in  order  to  transmit  a  message. 

ACTION  INTEGRAL.  {13}  The  action  integral  is  a  critical  factor  in  the  production 
of  damage.  It  relates  to  the  energy  deposited  or  absorbed  in  a  system.  This 
energy  cannot  be  defined  without  knowing  the  resistance  of  the  system.  The 
instantaneous  power  dissipated  in  a  resistor  is  I2R  and  is  expressed  in  watts. 
For  the  total  energy  expended,  the  power  must  be  integrated  over  time  to  get  the 
total  joules,  watt-seconds.  By  specifying  the  integral  of  i(t)2  over  the  time 
interval  involved,  a  useful  quantity  is  defined  for  application  to  any  resistance 
value.  In  the  case  of  lightning,  this  quantity  is  defined  as  the  action  integral 
and  is  specified  as  i(t)2dt  over  the  time  the  current  flows. 

ACTIVE  FAULT .  {10}  A  fault  that  can  produce  an  error  (for  some  input)  while 

executing  the  current  program. 

ACTUAL  TRANSIENT  LEVEL.  {13}  The  actual  transient  level  is  the  level  of 
transients  which  actually  appear  at  the  system  interfaces  as  a  result  of  the 
external  environment.  This  level  may  be  less  than  or  equal  to  the  transient 
control  level  but  should  not  be  greater. 

ADAPTIVE  FUZZY  SYSTEMS.  {20}  Fuzzy  controllers  with  the  ability  to  learn  and 
explain  their  reasoning. 

ADDRESSING  CAPACITY.  {6}  The  number  of  components  addressable  by  the  protocol 
used  on  a  given  data  bus . 

ADVISORY  CIRCULAR.  {18}  An  external  FAA  publication  consisting  of  nonregulatory 
material  of  a  policy,  guidance,  and  informational  nature. 

AIR  TRANSPORT  AIRCRAFT.  {18}  Aircraft  used  in  interstate,  overseas,  or  foreign 
air  transportation. 
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AIRCRAFT  LIGHTNING  INTERACTION.  {13}  An  encounter  with  lightning  that  produces 
sufficient  current  within  or  voltages  along  an  aircraft  skin  or  structure  to  pose 
a  threat  to  the  aircraft  electrical/electronic  systems,  as  a  result  of  a  direct 
lightning  attachment. 

AIRWORTHINESS  STANDARDS.  {18}  Parts  23,  25,  27,  29,  and  33  of  the  Code  of 
Federal  Regulations,  Title  14,  Chapter  1,  Subchapter  C. 

ALGORITHM .  (20)  A  set  of  well-defined  rules  for  the  solution  of  a  problem  in  a 
finite  number  of  steps. 

AMBIENT.  {16}  The  substance  which  absorbs  heat  from  the  heat  sink. 

ANALOG .  (20)  Pertaining  to  devices,  data,  circuits,  or  systems  that  operate  with 
variables  that  are  presented  by  continuously  measured  voltages  or  other 
quantities. 

ANALYTICAL  REDUNDANCY.  {7}  The  use  of  software  algorithms  which  use  known  mathe¬ 
matical  relationships  between  different  sensors  for  sensor  failure  detection  and 
replace  most  of  additional  redundant  sensor  hardware . 

ANALYT I  CAL  ROOT  S  OLUT I  ON .  {4}  Information  obtained  from  the  roots  of  the 

characteristic  equations  of  the  airplane  model  such  as  short— period  or  phugoid 
frequency  response. 

ANGLE  OF  ATTACK.  {4}  Angle  between  the  longitudinal  axis  of  an  aircraft  and  the 
direction  of  movement. 

ANISOTROPIC.  (19)  Having  different,  direction  dependent,  physical 

characteristics . 

ANODIZE.  {11}  A  preparation  by  electrolytic  process  that  deposits  a  protective 
oxide,  insulating  film  on  a  metallic  surface  (aluminum).  The  oxide  defeats 
electrical  bonding.  Alodine  and  iridite  finishes  on  aluminum  are  conductive. 

ANTAGONISTIC  QUALITY  FACTORS.  {17}  Quality  Factors  with  conflicting  attributes . 

APERTURE.  {11}  An  opening,  such  as  a  nonconductive  panel  joint,  slot,  or  crack, 
allowing  electromagnetic  energy  to  pass  through  a  shield. 

ARC .  {20}  The  part  of  a  semantic  network  that  connects  one  object  to  another. 

ARCHITECTURE.  {18}  The  design  and  interaction  of  components  of  a  computer 
system. 

ARTIFICIAL  INTELLIGENCE.  {16}  The  characteristics  of  a  machine  programmed  to 
imitate  human  intelligence  functions. 

ARTIFICIAL  INTELLIGENCE.  {20j  The  subfield  of  computer  science  concerned  with 
emulating  human  intelligence  by  use  of  software  and  hardware  techniques. 
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ASSISTANT .  {20}  An  Expert  System  that  performs  a  technically  limited  subset  of 
an  expert's  task. 

ASSOCIATIVE  MEMORY  NETWORK.  .{20}  A  network  where  different  input  patterns,  if 
sufficiently  similar,  become  associated  with  one  another  (trigger  the  same 
response) . 

ASSURANCE  ASSESSMENT.  {4}  Procedures  whose  purpose  is  to  ensure  that  a  proposed 
system  functions  according  to  design  specifications. 

ASYNCHRONOUS .  {20}  Operating  at  a  speed  determined  by  the  circuit  functions 

rather  than  by  timing  signals. 

ASYNCHRONOUS  MESSAGES.  {6}  Electronic  signals  with  transmission  times  that  are 
not  known  a  priori.  These  may  include  priority  signals  requiring  immediate 
access  to  the  bus. 

ATTACHMENT  POINT.  {13}  A  point  of  contact  of  the  lightning  flash  with  the 
aircraft. 

ATTENSQN.  {19}  A  unique  sound  used  on  the  flight  deck  for  alerting  the 
flightcrew  of  warning,  caution,  and  advisory  conditions. 

ATTRACTOR .  {20}  The  geometrical  pattern  toward  which  the  trajectory  of  a 

dynamical  system,  represented  by  a  curve  in  phase  space,  converges  in  the  course 
of  time. 

AUDIO  FREQUENCY  (AF) .  {11}  The  spectrum  (20  to  20,000  Hz)  of  human  hearing, 

often  defined  as  extending  from  approximately  20  Hz  to  50  kHz  and  sometimes  to 
150  kHz.  Audio  noise  is  nuisance  hum,  static,  or  tones  from  power  line  400  Hz, 
switching  regulator  and  digital  clock  harmonics,  or  HF ,  VHF  transmitter 
frequencies . 

AUTOFEATHER.  {16}  To  automatically  and  swiftly  feather  the  propeller  when  the 
engine  fails  to  drive  it. 

AUXILIARY  PROGRAMS .  {10}  Software  executed  occasionally. 

AVALANCHING  LATENT  FAULTS.  {10}  The  successive  activation  of  latent  faults. 
AVIONIC.  {18}  Electronic  equipment  used  in  aircraft. 

AXON.  {20}  The  pathway  that  carries  the  output  of  a  biological  neuron. 

B- FAULT .  {10}  A  fault  not  activated  by  the  baseline  program  (see  a-FAULT) . 

BABBLING  TRANSMITTER.  {18}  A  bus  user  that  transmits  outside  its  allocated  time. 

BACK  PROPAGATION.  {20}  An  algorithm  used  to  adjust  weights  connecting  neurons 
in  successive  layers  of  multi-layer  networks.  Back  propagation  learns  by  example 
and  repetition. 


3 


BACKSHELL.  {11}  Metal  shell  connecting  circuit  shields  or  overbraid  to  an 
electrical  connector. 

BACKWARD  CHAINING.  {20}  A  method  of  problem  solving  that  works  backward  from  a 
known  conclusion  in  an  attempt  to  find  a  path  of  reasoning  in  order  to  justify 
the  conclusion. 

BACKWARD  RECOVERY.  {9}  Restoration  of  the  system  to  some  previous  known  correct 
state  and  restarting  the  computation  from  that  point. 

BALANCED  CIRCUIT.  {11}  A  signal,  acting  line-to-line ,  between  two  conductors 
having  symmetrical  voltages  identical  and  equal  In  relation  to  other  circuits  and 
to  ground.  "Differential  mode"  is  line— to— line ;  "common  mode"  is  line  to  ground. 

BALANCED  CONFIGURATION.  {18}  A  bus  using  the  HDLC  protocol  that  connects  only 
primary  stations. 

BANDWIDTH  (BW) .  {11}  Frequencies  bounded  by  an  upper  and  lower  limit  in  a  given 
band  associated  with  electronic  devices,  filters,  and  receivers. 

BASELINE  PROGRAM.  {10}  A  set  of  continuously  executed  software  modules. 

BASIN  OF  ATTRACTION.  {20}  The  collection  of  all  possible  initial  conditions  of 
a  dynamical  system  for  which  the  trajectories  representing  that  system  in  phase 
space  will  converge  to  a  particular  attractor. 

BENIGN  FAULT.  {10}  A  fault  that  cannot  produce  an  error  while  executing  the 
current  program,  regardless  of  Input,  but  may  produce  an  error  for  some  other 
program. 

BIDIRECTIONAL  DATA  BUS.  {18}  A  data  bus  with  more  than  one  user  capable  of 
transmitting. 

BINARY.  {20}  Composed  of  or  characterized  by  two  parts  or  elements. 

BINARY  SEARCH.  {17}  A  searching  algorithm  in  which  the  search  population  is 
repeatedly  divided  into  two  equal  or  nearly  equal  sections. 

BIREFRINGENCE.  {19}  The  splitting  of  light  into  two  components,  where  each 
component  travels  at  a  different  velocity. 

BIT-ORIENTED  PROTOCOL.  {18}  A  communication  protocol  where  message  frames  can 
vary  in  length,  with  single  bit  resolution. 

BIT  TIME.  {6}  The  time  it  would  take  to  transmit  one  bit.  Usually  this  is 
"blank"  time  when  nothing  is  being  transmitted.  One  nth  of  the  bus  speed  (i.e. , 
on  a  1  kHz  bus,  the  bit  time  is  10“3  seconds). 

BITS.  {17}  Binary  digits. 
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BLACK  BOX.  {20}  A  component  having  known  input  and  output,  that  can  be  readily 
inserted  into  or  removed  from  a  specific  place  in  a  larger  system  without 
knowledge  of  the  component's  detailed  internal  structure. 

BLACKBOARD .  {20}  The  controlling  agent  in  a  blackboard  system  that  tracks 

activity  between  the  knowledge  sources. 

BLACKBOARD  SYSTEM.  {20}  An  Expert  System  that  uses  multiple  knowledge  sources 
that  share  data. 

BLOCK  TRANSFER.  {6}  A  data  transfer  mode  allowing  the  transfer  of  variable 
length  data  blocks. 

BOND .  ELECTRI CAL .  {11}  Electrical  connection  at  two  metallic  surfaces  securely 
joined  to  assure  good  conductivity  often  2 . 5-mfi  maximum  for  electrical/electronic 
units  and  IQ  for  electrostatic  dissipation  or  safety.  A  "faying  surface"  bond 
maintains  contact  between  relatively  large  or  long  surfaces.  Inherently  bonded 
parts  are  permanently  assembled  and  conductivity  exists  without  special 
preparation:  such  as  with  welding,  brazing. 

BOOLEAN  LOGIC.  {20}  The  basic  mathematics  needed  to  study  the  logic  design  of 
digital  systems.  Boolean  logi<£  consists  of  two  values  and  three  basic  operators. 

BRAID.  OVERBRAID.  {11}  Fine  metallic  conductors  woven  to  form  a  flexible  conduit 
or  cableway  and  installed  around  insulated  wires  to  provide  protection  against 
electric  fields  and  radio  frequencies.  Best  when  peripherally  connected  to 
backshells.  A  grounding  strap/jumper  may  be  made  of  braid. 

BREADTH  FIRST.  {20}  The  method  of  searching  for  solutions  by  considering  all 
possible  subgoals  on  one  level  before  proceeding  to  the  next  level. 

BRIDGE,  {18}  A  BIU  that  is  connected  to  more  than  one  bus  for  the  purpose  of 
transferring  bus  messages  from  one  bus  to  another,  where  all  the  buses  follow  the 
same  protocol. 

BROADBAND .  {12}  A  frequency  spectrum  which  is  wide  compared  to  the  bandwidth  of 
the  device  used  to  detect  it. 

BROADCAST .  {4}  Transmission  of  messages  to  all  terminals  without  reference  to 
the  identification  of  the  receiving  station  or  terminal. 

BROADCAST  CAPABILITY .  {6}  The  capacity  to  transmit  messages  to  all  terminals 

s imul taneous ly . 

BROADCAST  DATA  BUS .  {18}  A  data  bus  where  all  messages  are  transmitted  to  all 
bus  users. 

BUFFER .  {18}  Memory  used  to  hold  segments  of  the  data  transferred  between 

asynchronous  processes. 

BUS .  {18}  A  conductor  that  serves  as  a  common  connection  of  a  signal  to  multiple 
users . 
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BUS  CONTROT.T.F.R  (18)  The  electronic  unit  that  is  designed  to  control  the  bus 
communication  of  all  users  for  a  centrally  controlled  bus . 

BUS  INTERFACE  UNIT.  {18}  The  electronics  that  interface  the  host  CPU  of  an  LRU 
to  a  bus  medium. 

BUS  MESSAGE.  (18)  A  complete  set  of  bits  that  can  be  transferred  between  two  bus 
users . 

BUS  NETWORK.  (18)  The  collection  of  all  BIUs  and  bus  media  associated  with  one 
bus . 

BUS  OVERLOAD.  {18}  The  condition  that  exists  when  the  time  it  takes  to  transmit 
outstanding  messages  on  a  bus  exceeds  the  time  allotted  for  those  transmissions. 


BUS  USER.  {18}  Any  LRU  attached  to  a  bus. 

BYZANTINE  RESILIENCE.  {5}  A  fault  tolerant  process  which  is  tolerant  of 
intermittent  faults  that  can  send  good  information  part  of  the  time . 

CABLE  OR  HARNESS.  {11}  A  bundle  of  separate,  insulated,  electrical  circuits, 
shielded  or  unshielded,  usually  long  and  flexible  and  having  breakouts, 
terminations,  overbraid,  and  mounting  provisions  completely  assembled. 

CABLEWAY .  {11}  A  solid  metallic  housing  (liner,  foil,  coating)  surrounding  and 
shielding  insulated  electrical  conductors.  Also  called  conduit,  tray,  or 
raceway.  Crosswise  or  transverse  openings  or  breaks  in  the  metallic  cableway 
cause  noise  voltages  to  be  transferred  to  internal  wire  circuits . 

CANARD.  {16}  A  tail— first  aerodyne,  usually  with  auxiliary  horizontal  surface 
at  the  front  and  a  vertical  surface  at  the  back. 

CAT  Ilia  LANDING.  {6}  One  of  several  landing  categories  defined  in  FAR  91.  CAT 
Ilia  implies  the  need  for  an  instrument  landing  approach. 

CENTRAL  BUS  CONTROL.  {18}  The  bus  control  approach  where  a  single  electronic 
unit  attached  to  a  bus  controls  all  the  communication  of  the  bus  users . 

CENTRAL  CONTROL.  {6}  Control  from  one  master,  whether  stationary  or  non¬ 
stationary. 

CERTAINTY  FACTOR.  (20)  A  value  that  represents  the  level  of  belief  associated 
with  a  fact  or  a  rule. 

CERTIFICATION.  {18,20}  The  process  of  obtaining  FAA  approval  for  the  design, 
manufacture,  and/or  sale  of  aircraft  and  associated  systems,  subsystems,  and 
parts . 

CHARACTER-ORIENTED  PROTOCOL.  {18}  A  communication  protocol  where  messages  can 
vary  in  length,  with  single  character  resolution. 
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CHARGE  TRANSFER.  {13}  The  integral  of  the  current  over  its  entire  duration, 
i(t)dt,  in  coulombs. 

CHECKSUM .  (18}  An  error  detection  code  produced  by  performing  a  binary  addition, 
without  carry,  of  all  the  words  in  a  message. 

CHOT.F.STERTC.  {19}  A  liquid  crystal  phase  with  molecules  parallel  to  each  other 
but  twisting  slightly  from  layer  to  layer. 

CHORD.  {4}  The  straight  line  segment  intersecting  or  touching  an  airfoil  profile 
at  two  points. 

CLOSED— LOOP .  {18}  A  system  where  the  output  is  a  function  of  the  input  and  the 
system's  previous  output. 

CLOSED-LOOP.  {20}  A  family  of  automatic  control  units  linked  together  with  a 
process  to  form  an  endless  chain;  the  effects  of  control  action  are  constantly 
measured  so  that  if  the  controlled  quantity  departs  from  the  norm,  the  control 
units  act  to  bring  it  back. 

CLUSTERING .  (20)  A  technique  to  group  similar  objects  together  under  the  same 

label. 

CODE.  (17)  The  subset  of  software  which  exists  for  the  sole  purpose  of  being 
loaded  into  a  computer  to  control  it. 

CODIFYING.  (20)  A  method  of  representing  knowledge  or  data  so  they  can  be  stored 
in  a  knowledge  base  or  database  for  access  by  a  computer. 

COLLEAGUE .  (20)  An  Expert  System  that  performs  a  significant  subset  of  an 

expert's  task. 

COMBINER.  (19)  A  screen  designed  to  reflect  selected  wavelengths  of  light  while 
remaining  transmissive  for  others. 

GOMMAND /RESPONSE.  {6}  "Operation  of  a  data  bus  system  such  that  remote  terminals 

receive  and  transmit  data  only  when  commanded  to  do  so  by  the  controller.  ( - 

STD-1553  Designer's  Guide,  1983,  p.  II-3.) 

GOMMAND/RFSPONSF.  DATA  BUS.  {18}  A  data  bus  whose  protocol  initiates  each  data 
transfer  with  a  command  and  terminates  the  transfer  after  a  proper  response 
received . 

GGMMON  MODF.  IMPEDANCE.  (11)  Impedance  or  resistance  shared  by  two  or  more 
circuits  so  that  noise  voltages/currents  generated  by  one  are  impressed  on  t  e 

others  . 

GOMMON  MODE  REJECTION.  {11}  The  ability  of  wiring  or  an  electronic  device  to 
reject  common  mode  (line— to— ground)  signals  and  maintain  fidelity  o  l  eren 
mode  ( 1 ine— to— 1 ine )  signals. 


7 


COMMON  MODE  SIGNAL.  (11)  Identical  and  equal  signals  on  input  conductors  or  at 
the  terminals  of  a  device  relative  to  ground. 


COMPLEMENTARY  QUALITY  FACTORS .  (17)  Quality  Factors  with  interrelated 

attributes . 

COMPONENT  DAMAGE,  {13}  Condition  arising  when  the  electrical  characteristics  of 
a  circuit  component  are  permanently  altered  beyond  its  specifications. 

CONDUCTED  EMISSION  (CE)  OR  INTERFERENCE.  {11}  Voltage/current  noise  signals 
entering  or  leaving  a  unit  on  interface  conductors.  Emission  is  the  general 
term,  interference  is  undesired  noise. 

CONFIGURATION  MANAGEMENT .  {18}  The  precise  control  and  documentation  of  the 

configuration  of  an  entity  at  any  time  during  its  development  and  deployment. 

CONNECTION  WEIGHT.  {20}  A  method  of  representing  the  strength  of  the  connection 
between  nodes . 

CONTENT  ADDRESSING.  {6}  The  system  of  Identifying  message  recipients  based  on 
information  embedded  in  the  message.  This  is  in  contrast  to  destination  terminal 
addresses . 

CONTENTION  PROTOCOL.  {18}  A  protocol  that  allows  users  to  randomly  access  the 
bus  at  any  time.  When  bus  contention  results,  each  user  tries  again  to  access 
the  bus  without  contention. 

CONTROL  LAW.  {7}  The  physical  relationship  between  various  sensors  and  control 
surfaces . 

CONTROL  REGISTER.  {18}  A  register  in  an  IC  controller  that  receives  commands 
from  a  host  processor. 

CONTROL  STRUCTURES .  {17}  Programming  constructs  which  direct  the  flow  of 

control . 

CONVENTIONAL  PROGRAMMING .  {20}  The  use  of  standard  programming  languages,  as 

opposed  to  application  development  languages,  financial  planning  languages,  query 
languages,  and  report  programs. 

CONVERGENCE .  {20}  The  point  when  the  outputs  of  a  Neural  Network  are  no  longer 
changing . 

CORONA.  {13}  A  luminous  discharge  that  occurs  as  a  result  of  an  electrical 
potential  difference  between  the  aircraft  and  the  surrounding  atmosphere. 

COUPLING .  {11}  The  transfer  of  energy  between  wires  or  components  of  a  circuit 
electrostatically,  electromagnetically ,  or  directly . 

COVERAGE .  {5}  The  conditional  probability  of  the  system  successfully  recovering 
from  a  component  fault  and  continuing  to  perform  the  intended  functions 
correctly,  given  the  presence  of  the  fault.  Coverage  is  the  measure  of 
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effectiveness  of  a  system' s  utilization  of  redundant  hardware .  Coverage  can  be 
qualified  and  applied  to  many  different  components  of  a  system  and  phases  of 
recovery  process.  Examples  include,  fault  detection  coverage,  fault  isolation 
coverage,  latent  fault  coverage,  sensor  failure  coverage,  and  memory  failure 
coverage . 

COVERAGE .  {7}  The  percent  confidence  level  of  a  given  analytical  redundancy 

fault  detection  and  isolation  algorithm  for  all  types  of  faults . 

COVERAGE .  (9)  The  probability  that  when  a  fault  occurs,  it  will  be  detected  and 
recovery  from  the  fault  will  be  successful. 

CRISP  SET.  {20}  The  membership  concept  used  in  traditional  system  modelling, 
where  objects  are  either  in  or  out  of  the  set  with  no  intermediate  step. 

CRITICAL.  {13}  Functions  whose  failure  would  contribute  to  or  cause  a  failure 
condition  which  would  prevent  the  continued  safe  flight  and  landing  of  the 
aircraft. 

CROSS  COUPLING  (CROSSTALK}.  {11}  Transfer  of  signals  from  one  channel,  circuit, 
or  conductor  to  another  as  an  undesired  or  nuisance  signal  or  the  resulting 
noise . 

DAMAGE.  {11}  The  irreversible  failure  of  a  component. 

DATA  BUS .  {6,18,19}  A  system  for  transferring  data  between  discrete  pieces  of 
equipment  in  the  same  complex. 

DATA  BUS  PROTOCOL.  {18}  The  set  of  rules  that  governs  the  transfer  of  data 
between  data  bus  users . 

DATA  DRIVEN.  {20}  Describing  the  execution  of  a  program  in  a  data  flow  system, 
in  which  an  instruction  is  carried  out  whenever  all  its  input  values  are  present. 

DATA  LATENCY.  {6,18}  The  delay  from  the  time  when  a  piece  of  information  becomes 
available  at  a  source  terminal  to  the  time  it  is  received  at  the  destination. 


DATA  LINK  ASSURANCE  OF  RECEIPT.  {6}  The  guarantee  of  good  data  through  the  data 
link  level. 

DATA  REASONABLENESS  CHECK.  {18}  A  check  performed  to  see  if  a  value  of  data  is 
within  reasonable  bounds  for  the  given  context. 

dB^iV.  (12)  Decibels  referred  to  one  microvolt.  Zero  db  represents  one  micro¬ 
volt  . 

DECIBEL  (dB) .  (11,12)  Decibel  expresses  the  ratio  between  two  amounts  of  power, 
Pi  and  P2,  at  two  separate  points  in  a  circuit.  By  definition,  the  number  of  dB 
=»  10  log  to  the  base  10  of  (P1/P2)  .  For  special  cases,  when  a  standard  power 
level  P2  =*  1  mW  or  1  W  or  1  kW,  then  the  ratio  is  defined  as  "dBm,"  "dBw,"  or 
"dBKW."  Because  P  -  V2/R  and  also  I2R,  decibels  express  voltage  and  current 
ratios.  Ideally,  the  voltages  and  currents  are  measured  at  two  points  having 


9 


identical  impedances.  By  definition,  dB  =  20  log  V1/V2  and  dB  =  log  11/12.  For 
convenience,  V2  or  12  are  often  chosen  as  1  /iV  or  1  /iA  and  the  ratio  is  defined 
as  dB  above  a  fiV  or  dB  above  a  fj, A  when  graphing  emission  or  susceptibility 
limits. 

DECLARATIVE.  {20}  Generally,  the  knowledge  found  in  the  knowledge  base; 
independent  knowledge  that  does  not  contain  procedures  or  methods  of  handling 
other  knowledge. 

DECOUPLED  MANEUVERS .  {4}  Changes  in  an  aircraft's  direction  and  attitude  in  one 
axis  without  affecting  direction  or  attitude  in  other  axes . 

DEDUCTIVE.  {20}  Learning  by  logical  inference  or  inferring  from  available 
knowledge . 

DEFAULT  DATA.  {18}  An  alternative  value  used  for  a  parameter  whenever  the  normal 
data  is  not  supplied. 

DEFUZZIFICATION .  {20}  The  process  of  translating  fuzzy,  or  non-crisp  values  into 
crisp,  clearly  defined  values. 

DEMON.  {20}  A  procedure  activated  by  changing  or  accessing  values  in  a  database. 

DENDRITE .  {20}  The  pathway  that  carries  the  input  of  a  biological  neuron. 

DEPTH  FIRST.  {20}  A  method  of  searching  for  a  solution  by  pursuing  each  branch 
of  the  search  tree  to  the  end  before  considering  another  branch. 

DESIGN  ERROR.  {4}  A  functional  flaw  resulting  from  a  misinterpretation  of  the 
specifications  of  the  system. 

DESIGN  MARGIN.  {13}  The  difference  between  the  equipment  transient  design  levels 
and  the  transient  control  level. 

DETERMINISTIC .  {6}  A  system  where  all  parameters  are  known,  as  opposed  to  a 
statistical  system  where  the  outcome  is  subject  to  the  laws  of  probability. 

DETERMINISTIC  PROTOCOL.  (18)  A  protocol  where  all  parameters  are  known  so  that 
its  various  states  are  predictable  in  sequence  and  time. 

DIAGNOSTIC  FILTER .  {7}  An  analytical  algorithm  which  processes  data  from  N 

functionally  related  sensors.  The  data  are  used  to  estimate  some  sensor  outputs 
and  assess  the  correct  functioning  of  the  sensors. 

DICHROIC .  {19}  Having  different  light  absorption  characteristics  based  on 

incident  polarization  direction. 

DIELECTRIC.  {19}  Having  an  insulating  property  with  respect  to  an  electrical 
field. 

DIELECTRIC  STRENGTH .  {11}  Voltage  withstand  capability  that  an  insulating 

material  sustains  before  destructive  arcing  and  current  flow,  usually  expressed 
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in  volts  per  mil  thickness.  Dielectric  withstand  voltage  is  the  voltage  level 
at  which  insulation  breakdown  occurs . 

DIFFERENTIAL  MODE  (DM1  SIGNAL.  {11}  The  signal  in  a  two-wire  circuit  measured 
from  line-to-line . 

DIGITAL  DATA  BUS .  {18}  A  data  bus  that  uses  digital  electronic  signals. 

DIRECT  EFFECTS .  {13}  Any  physical  damage  to  the  aircraft  or  onboard  systems  due 
to  the  direct  attachment  of  the  lightning  channel.  This  includes  tearing, 
bending,  burning,  vaporization,  or  blasting  of  aircraft  surfaces  or  structures, 
and  damage  to  electrical/electronic  systems. 

DISSIMILAR  REDUNDANCY.  {18}  The  redundancy  of  systems  that  provide  a  redundancy 
of  function,  but  by  a  different  form. 

DISSIMILAR  SOFTWARE.  {18}  Redundant  computer  programs  that  provide  a  redundancy 
of  function,  but  by  a  different  form. 

DISTRIBUTED  BUS  CONTROL.  {18}  The  bus  control  approach  where  the  total 
communication  control  job  is  distributed  across  the  bus  users,  each  controlling 
the  communications  during  its  period  of  responsibility. 

DISTRIBUTED  CONTROL.  {6}  Concurrent  control  from  multiple  points  in  the  data  bus 
system. 

DOT  PRODUCT.  {20}  The  inner  product  of  vectors  (xx . Xn)  and  (ylt  .  .  .  ,yn)  from 

n-dimensional  euclidean  space  is  the  sum  of  s^,  as  i  ranges  from  1  to  n. 

DOUBLE  FAIL— OPERATIONAL  SYSTEM.  {4}  A  quadruplex  (or  higher)  redundant  flight- 
control  system  which  is  designed  to  incur  failures  in  two  redundant  lanes  (or 
channels)  before  it  fails. 

DUAL-DUAL  ARCHITECTURE.  {4}  Two  parallel  dual  computers  with  a  voting  plane  at 
the  output  of  each  dual  computing  lane . 

DUAL  FAIL-OPERATIONAL.  {7}  A  reliability  requirement  placed  on  a  system  which 
requires  the  system  to  be  operational  after  two  failures  have  occurred. 

DUAL  GROUND.  {11}  Equipment  case  ground/return  through  two  independent  circuit 
paths  to  structure  implemented  in  flammable  zones  and  water  leakage  areas-each 
path  meeting  electrical  conductivity  (resistance)  requirements. 

F.T.F.rTRTC  FIELD.  {11}  High- impedance ,  radiated  voltage  field,  positive  or 
negative,  from  a  voltage  source  as  contrasted  to  a  low-impedance  magnetic  field 
from  a  current  source. 

ELECTROMAGNETIC  COMPATIBILITY  (EMC) .  (11)  Operation  within  performance 
specification  in  the  intended  electromagnetic  interference  environment. 
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ELECTROMAGNETIC  INTERFERENCE  (EMI).  {11}  Conducted  and  radiated  voltage/current 
noise  signals,  broadband  (BB)  or  narrow  band  (NB) ,  that  degrade  the  specified 
performance  of  equipment. 

ELECTROMIGRATION .  {5}  Drifting  of  metal  atoms  toward  the  cathode  of  a  cathode 
ray  tube . 

ELECTROSTATIC  CHARGE.  {11}  Electric  potential  energy  with  a  surrounding  electric 
field,  uniform  or  nonuniform,  moving  or  at  rest,  on  a  material. 

EMISSION .  {11}  Voltage/current  noise  on  a  wire  or  in  space.  Broadband  emission 
has  uniform  spectral  energy  over  a  wide  frequency  range  and  can  be  identified  by 
the  response  of  a  measuring  receiver  not  varying  when  tuned  over  several  receiver 
"bandwidths . "  Or,  energy  present  over  a  bandwidth  greater  than  the  resolution 
bandwidth  where  individual  spectral  components  cannot  be  resolved.  Broadband 
(BB)  may  be  of  two  ‘types:  (1)  impulse  and  coherent  varies  20  dB  per  decade  of 
bandwidth  and  (2)  random  or  statistical,  varies  10  dB  per  decade.  A  narrow  band 
(NB)  emission  or  signal,  sometimes  called  continuous  wave,  occurs  at  a  discrete 
frequency  and  does  not  vary  with  bandwidth. 

EMPIRICAL  MODEL.  {20}  The  model  of  a  system  based  on  data  and  the  principles  of 
statistics.  Empirical  models  produce  relationships,  not  insight. 

EMULATION.  {18}  The  duplication  of  the  behavior  of  a  system  with  a  different 
system. 

ENVELOPE  LIMITING.  {4}  General  or  additional  limits  imposed  on  the  structural, 
"g"  limits,  speed,  attitude,  etc.  of  the  aircraft.  In  some  cases,  envelope 
limiting  imposes  additional  constraints  on  the  envelope  that  cannot  be  exceeded 
regardless  of  pilot  inputs. 

EQUIPMENT  TRANSIENT  DESIGN  LEVEL.  {13}  The  level  of  transients  which  the 
equipment  is  qualified  to  withstand. 

EQUIPMENT  TRANSIENT  SUSCEPTIBILITY  LEVEL.  {13}  The  transient  level  which  will 
result  in  damage  or  upset  to  the  system  components.  This  level  will  be  greater 
than  the  equipment  transient  design  level. 

EQUIVALENCE  STATEMENT.  {17}  A  FORTRAN  statement  which  equates  two  variable 
names . 

ERROR.  {4}  A  mistake  in  specification,  design,  production,  maintenance,  or 
operation  of  a  system  causing  undesirable  performance. 

ERROR.  {8}  A  state  of  the  system  which  (in  the  absence  of  any  corrective  action 
by  the  system)  could  lead  to  a  failure  that  would  not  be  attributed  to  any  event 
subsequent  to  the  error.  (More  accurately  known  as  an  erroneous  state.) 

ERROR  MASKING.  {18}  The  process  of  masking  the  presence  of  avionic  errors, 
possibly  by  using  an  electronic  voter  to  override  an  erroneous  input  with  the 
values  of  substitute  inputs. 
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EVENT .  {20}  A  change  to  the  blackboard  of  a  Blackboard  System. 


EVENT ,  EXTREMELY  IMPROBABLE .  {4}  An  event  with  a  probability  of  occurrence  on 

the  order  of  10-9  or  less. 

EVENT.  IMPROBABLE.  {4}  An  event  with  a  probability  of  occurrence  on  the  order 
of  10-5  or  less. 

EVENT.  PROBABLE.  (4)  An  event  with  a  probability  of  occurrence  on  the  order  of 
10-5  or  greater. 

EXPERT .  (20)  1.  An  Expert  System  that  approaches  an  expert's  level  of 

performance  within  a  given  domain.  2.  A  person  who  has  mastered  solving  specific 
types  of  problems. 

EXPERT  SYSTEM.  {20}  A  computer  system  designed  to  simulate  the  problem  solving 
behavior  of  a  human  expert. 

EXPERT  SYSTEM  SHELL.  {20}  An  Expert  System  development  tool  and  run-time 
environment  with  a  modifiable  knowledge  base. 

EXTERNAL  ENVIRONMENT .  {13}  Characterization  of  the  natural  lightning  environment 
with  idealized  waveforms  for  engineering  purposes. 

FACETTE .  {20}  A  piece  of  knowledge  in  a  frame. 

FAIL-OPERATIONAL .  {7}  A  reliability  requirement  placed  on  a  system  which 
requires  the  system  to  be  operational  after  a  single  failure  has  occurred. 

FAIL-SAFE.  {7}  A  reliability  requirement  placed  on  a  system  which  requires  that 
safe  flight  not  be  hindered  even  after  a  failure. 

FAIL-SAFE.  {18}  A  design  philosophy  that  ensures  that  any  failure  in  a  system 
does  not  result  in  an  unsafe  condition  after  the  failure. 

FAILURE.  {4}  The  inability  of  a  system,  subsystem,  unit,  or  part  to  perform 
within  specified  limits. 

FAILURE .  {5}  The  deviation  of  system  behavior  from  specifications  (arithmetic 

failure,  storage  failure,  flight  control  function  failure.) 

FAILURE .  {8}  The  situation  when  the  external  behavior  of  a  system  does  not 

conform  to  that  prescribed  by  the  system  specification. 

FAILURE.  HARD.  {5}  Repeated  use  of  the  same  input  and  initial  conditions  results 
in  the  same  incorrect  response. 

FAILURE .  HIDDEN .  {4}  A  failure  that  is  not  manifested  at  the  time  of  its 

occurrence . 
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FAILURE  MECHANISM.  {5}  Any  situation  that  could  produce  an  error  condition. 
Examples  of  failure  mechanisms  include  metal  migration,  voltage  overstress,  and 
lack  of  air-conditioning. 

FAILURE.  PERMANENT.  {5}  Repeated  use  of  the  same  input  and  initial  conditions 
results  in  the  same  incorrect  response. 

FAILURE.  SOFT.  (5)  Repeated  use  of  the  same  input  and  initial  conditions  does 
not  result  in  the  same  incorrect  response. 

FAILURE.  TEMPORARY.  {5}  Repeated  use  of  the  same  input  and  initial  conditions 
does  not  result  in  the  same  incorrect  response. 

FAILURE.  TRANSIENT.  {5}  Repeated  use  of  the  same  input  and  initial  conditions 
does  not  result  in  the  same  incorrect  response. 

FALL-TIME .  {12}  The  time  required  for  pulse  amplitude  to  go  from  a  predefined 
magnitude  to  a  given  level. 

FALSE  ALARM.  {7}  The  declaration  of  a  fault  by  a  fault  detection  monitor  or 
algorithm  when  there  is  no  fault. 

FAULT .  {4}  An  error  in  the  operation  of  a  system. 

FAULT .  {5}  The  phenomenological  reason  for  a  failure  (open  wire,  stuck— at  fault, 
design  fault,  etc.).  In  general,  any  condition  preventing  a  digital  component 
from  correctly  changing  state  when  directed  to  change  by  input  parameters.  For 
electrical  components  there  is  a  one— to— one  correspondence  between  faults  and 
failures.  The  situation  is  not  so  simple  with  digital  circuits.  For  if  the 
circuit  is  S-A-l,  any  input  causing  a  one  output  will  be  correctly  processed;  a 
little  like  the  stopped  clock  that  is  correct  twice  per  day.  For  a  processor 
having  a  million  or  so  logic  gates,  it  is  not  possible  to  test  for  all  the 
combinations  of  input  and  output  states. 

FAULT .  {8}  The  adjusted  cause  of  error. 

FAULT  AVOIDANCE.  {9}  The  attempt  to  prevent  any  software  faults  in  the  final 
delivered  product  through  disciplined  software  development  practices,  testing, 
and  IV&V. 

FAULT  CONTAINMENT.  {6,9}  The  capacity  of  a  system  to  prohibit  errors  and/or 
failures  from  propagating  from  the  source  throughout  the  system. 

FAULT  CURRENT.  {11}  The  maximum  current  (magnitude  and  duration)  flowing  through 
a  fault  point.  This  current  is  equal  to  the  supply  voltage  divided  by  the  dc 
resistance  of  power  line  leads,  circuit  breakers,  and  the  current  return  in  wire 
or  structure. 

FAULT  DETECTION.  {6}  The  capacity  of  a  system  to  determine  the  occurrence  of 
erroneous  operation. 
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FAULT  DETECTION.  {7}  The  determination  that  a  sensor  is  faulted  by  using  a 
software  algorithm. 

FAULT .  HARD .  {4)  A  defect  in  the  hardware  or  software  of  a  digital  control 

system  that  permanently  affects  some  functional  performance  of  the  system. 

FAULT  INSERTION.  {4}  A  testing  technique  used  to  obtain  information  about  data 
latency  and  built-in  test  coverage  of  a  digital  flight— control  system. 

FAULT  ISOLATION.  (6)  The  capacity  of  a  system  to  isolate  a  failure  to  the 

required  level  so  it  can  reconfigure. 

FAULT  ISOLATION.  (7)  The  determination  that  a  particular  sensor  is  faulted  by 
using  a  software  algorithm. 

FAULT.  LATENT.  {5}  A  fault  which  has  not  yet  caused  a  failure.  (For  example, 
a  fault  In  a  memory  chip  that  is  not  being  used  for  the  foreground  program  or  in 
this  particular  mode  of  the  system  is  a  latent  fault.) 

FAULT.  SOFT.  (4)  A  transient  defect  in  the  software  of  a  digital  flight-control 
system  that  can  be  overcome  by  error— correctable  code  or  by  recycling  of  power 
to  the  computer  system. 

FAULT .  STUCK-AT .  (5)  A  logic  signal  which  remains  at  zero  (S-A-O)  or  one 

(S-A-l). 

FAULT  TOT  FRANflF.  (6,9)  The  capability  to  endure  errors  and/or  failures  without 
causing  total  system  failure. 

FAULT  TOLERANCE.  (7)  Accommodation  of  sensor  hardware  faults  based  on  some  type 
of  comparator  scheme. 

FAULT  TOLERANCE  (18)  The  ability  of  a  system  to  continue  operation  after  a 
fault,  possibly  in  a  degraded  condition. 

FAULT  TQT.F.RANT  (4,9)  Software  which  continues  to  operate  satisfactorily  in  the 
presence  of  faults . 

FAULT  TQT.F.RANT  SYSTEM.  (5)  A  system  that  continues  to  function  although  certain 
components  may  have  faults . 

FAULT  TREE  ANALYSIS.  (4)  A  top-down  deductive  analysis  that  identifies  the 
conditions  and  functional  failures  necessary  to  cause  a  defined  failure 
condition.  The  fault  tree  can  be  used  to  establish  the  probability  of  the 
ultimate  failure  condition  occurring  as  a  function  of  the  estimated  probabilities 
of  contributory  events . 

FEDERAL  AVIATION  REGULATIONS.  {18,19}  Subchapter  C  of  the  Code  of  Federal 
Regulations,  Title  14,  Chapter  1. 

FEED  FORWARD  NEURAL  NETWORK.  {20}  A  Neural  Network  where  the  only  connections 
are  from  a  neuron  in  one  layer  to  a  neuron  in  the  next  layer. 
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FILTER.  (11)  Device  or  unit  that  passes  or  rejects  a  frequency  band  and  is 
designed  to  block  noise  from  entering  or  leaving  a  circuit  or  unit. 

FILTER.  {20}  A  transmission  network  used  in  electrical  systems  for  the  selective 
enhancement  of  a  given  class  of  input  signals. 

FINITE  STATE  MACHINE.  {18}  A  state  machine  with  a  finite  number  of  states. 

FLIGHT  CODE .  {4}  The  application  software  of  the  digital  flight— control  system. 

FLIGHT-CRITICAL.  {4,7,18}  A  description  of  functions  whose  failure  would 
contribute  to  or  cause  a  failure  condition  preventing  the  continued  safe  flight 
and  landing  of  the  aircraft. 

FLI GHT-ES S  ENTI AL .  {4,18}  A  description  of  functions  whose  failure  would 
contribute  to  or  cause  a  failure  condition  which  would  significantly  affect  the 
safety  of  the  airplane  or  the  ability  of  its  crew  to  cope  with  adverse  operating 
conditions . 

FLIGHT-NONESSENTIAL  FUNCTION .  {18}  A  function  whose  failure  could  not 

significantly  degrade  aircraft  capability  or  crew  ability. 

FLIGHT-PHASE  CRITICAL.  {4}  A  description  of  functions  which  are  critical  only 
during  certain  phases  of  flight. 

FLY-BY-GLASS .  {16}  Flight  control  system  where  fiber  optics  carry  the  signal. 

FLY-BY-LIGHT .  {4,16}  Flight  control  system  where  fiber  optics  carry  the  signal. 

FLY-BY-WIRE .  {4,16}  Flight  control  system  with  electric  signaling. 

FORWARD  CHAINING.  {20}  A  method  of  solving  problems  by  beginning  with  certain 
data  and  moving  down  the  inference  chain  until  a  solution  is  reached. 

FORWARD  RECOVERY.  {9}  Restoration  of  the  system  to  a  consistent  state  by 
compensating  for  inconsistencies  found  in  the  current  state  so  that  the  system 
may  continue  processing. 

FOURIER  TRANSFORM.  {12}  A  mathematical  method  for  deriving  the  frequency 
spectrum  from  a  time  dependent  function. 

FRAME .  {18}  A  formatted  block  of  data  words  or  bits  that  is  used  to  construct 
messages . 

FRAME.  {20}  A  way  of  representing  Expert  System  knowledge  that  consists  of  a  set 
of  slots  that  contain  data. 

FRAME  LABEL.  {20}  A  unique  frame  identification. 

FUNCTIONAL  PARTITIONING.  {18}  The  partitioning  of  system  functions  by  placing 
each  group  of  users,  which  share  a  common  function,  on  different  data  buses. 
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FUZZIFICATION.  {20}  The  process  of  converting  crisp  inputs  into  fuzzy  values. 


FUZZY  CONTROL  VARIABLE .  {20}  A  parameter  whose  value  determines  the  action  taken 
by  fuzzy  rules . 

FUZZY  EXPERT  SYSTEM.  {20}  An  Expert  System  that  uses  fuzzy  logic  techniques  to 
solve  problems. 

FUZZY  LOGIC.  {20}  The  theory  of  representing  vague  or  imprecise  concepts  to 
model  inherent  conditions. 

FUZZY  SET.  {20}  An  extension  of  the  concept  of  a  set,  in  which  the 
characteristic  function  which  determines  membership  of  an  object  in  the  set  can 
take  on  any  value  between  0  and  1 . 

FUZZY  TERMS.  {20}  Words  used  for  descriptions  that  may  not  be  precise  in 
determining  set  memberships. 

GATEWAY.  {18}  A  bus  user  that  is  connected  to  more  than  one  bus  for  the  purpose 
of  transferring  bus  messages  from  one  bus  to  another,  where  the  buses  do  not 
follow  the  same  protocol. 

GENERAL  AVIATION  AIRCRAFT.  {18}  The  non-air  transport  civil  aircraft. 

GETTER.  {19}  A  metal  alloy  used  in  a  vacuum  tube  to  absorb  residual  gasses. 

GENERATOR  POLYNOMIAL.  {18}  The  polynomial  code  that  is  used  to  generate  the 
remainder  in  the  division  of  the  CRC  check. 

GIGABIT.  {16}  One  billion  bits. 

GLASS  COCKPIT.  {9}  Advanced  state-of-the-art  electronic  displays  utilizing  flat 
panel  and/or  cathode  ray  tube  display  technology  for  cockpit  instrumentation. 

GLOBAL  STATE.  {18}  A  state  that  represents  the  condition  of  the  entire  network 
being  modeled,  including  senders,  receivers,  and  the  communication  link. 

GRACEFUL  DEGRADATION.  {20}  A  programming  technique  to  prevent  catastrophic 
system  failure  by  allowing  the  machine  to  operate,  though  in  a  degraded  mode, 
despite  failure  or  malfunction  of  several  integral  units  or  subsystems. 

GRAY  SCALE.  {19}  A  series  of  tones,  varying  from  black  to  white. 

GROUND .  {11}  A  generic  term  having  multiple  meanings  and  indicating  a  circuit 

return  path  or  a  voltage  reference:  not  "zero"  voltage  reference.  Four  hundred 
millivolts  of  noise  voltage  is  common  on  "quiet"  grounds.  There  are  several 
types  of  returns  and  references. 

GROUND  EFFECT.  {4}  Increase  in  aircraft  lift  when  operating  near  the  ground. 

HALF-DUPLEX .  {18}  Bidirectional  communication  between  two  entities  on  a  single 
channel  by  each  having  a  turn  to  control  the  channel. 
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HAMMING  CODE.  {18}  An  error  detection  and  correction  code  based  on  the  Hamming 
distance . 

HAMMING  DISTANCE.  {18}  The  number  of  bit  positions  in  which  two  binary  words 
differ. 

HANDSHAKING .  {18}  The  reciprocal  responses  given  by  two  electronic  systems  to 

sequence  the  steps  of  a  transfer  of  data  between  them. 

HARD  FAILURE.  {12}  A  failure  that  requires  a  reset  of  the  equipment. 

HARDWARE .  {17}  The  physical  components  of  a  computer. 

HARDWARE-IN-THE-LOOP  SIMULATION.  {18}  A  partial  simulation  of  a  system;  part  of 
the  actual  system  is  used  in  the  simulation. 

HAZARD  FUNCTION.  {8}  The  conditional  probability  that  a  fault  is  exposed  in  the 
interval  t  to  At  given  that  the  fault  did  not  occur  prior  to  time  t. 

HERMETIC .  {19}  Having  an  airtight  seal. 

HETEROASSOCIATIVE .  {20}  A  Neural  Network  where  output  patterns  are  distinct  from 
input  patterns . 

HEURISTIC.  {20}  Any  rule  of  thumb,  strategy,  or  technique  used  to  limit  the  time 
required  to  search  for  solutions  in  large  problem  spaces . 

HEURISTIC  REASONING.  {20}  Using  an  expert's  rules  of  thumb,  in  the  absence  of 
precise  control  mechanisms,  to  reduce  the  space  that  must  be  searched  for  a 
solution. 

HIDDEN  LAYER.  {20}  The  middle  layer  in  a  Neural  Network  which  takes  outputs  from 
the  input  layer,  processes  them,  and  passes  them  to  the  output  layer. 

IMMUNITY.  {11}  Capability  of  a  circuit  or  unit  to  operate  within  performance 
specification  in  a  specified  electromagnetic  interference  environment. 

INDIRECT  EFFECTS.  {13}  Voltage  and/or  current  transients  induced  by  lightning 
in  aircraft  electrical  wiring  which  can  produce  upset  and/or  damage  to  components 
within  electrical/electronic  systems. 

INDUCED  VOLTAGES.  {13}  A  voltage  produced  around  a  closed  path  or  circuit  by 
changing  magnetic  or  electric  fields  or  structural  IR  voltages. 

INDUCTIVE .  (20)  Learning  by  information  repetition. 

INFERENCE  CHAIN.  {20}  The  path  of  reasoning  that  the  inference  engine  follows 
to  find  a  solution  to  the  problem. 

INFERENCE  ENGINE.  {20}  The  part  of  an  Artificial  Intelligence  system  that  uses 
knowledge  in  the  knowledge  base  and  acquired  knowledge  about  the  problem  to  form 
an  expert  solution. 
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INFERENCE  MECHANISM.  {20}  Controls  the  use  of  the  knowledge  base  and  databases 
when  solving  a  problem. 

INITIALIZATION .  {6}  Setting  the  beginning  parameters  and  values  on  system  power- 
up.  For  redundant  systems  this  includes  setting  the  initial  configuration  of  the 
system. 

INPUT  LAYER .  {20}  The  first  layer  of  neurons  in  a  Neural  Network.  The  input 
layer  accepts  the  input  values  and  passes  them  to  the  hidden  layer.  The  input 
layer  does  not  process  data. 

INTERNAL  ENVIRONMENT.  {13}  The  fields  and  structural  IR  potentials  produced  by 
the  external  environment,  along  with  the  voltages  and  currents  induced  by  them. 

INTERRUPT  VECTOR.  {18}  The  address  that  points  to  the  beginning  of  the  service 
routine  for  an  interrupt. 

INTERRUPT  VECTOR  TABLE.  {18}  The  table  of  interrupt  vectors  for  all  interrupts 
serviced  by  a  system. 

ISOLATION.  {11}  Electrical  separation  and  insulation  of  circuits  from  ground  and 
other  circuits  or  arrangement  of  parts  to  provide  protection  and  prevention  of 
uncontrolled  electrical  contact. 

ISOTROPIC .  {19}  Having  the  same  physical  properties  in  all  directions. 

JOULE.  {12}  A  unit  of  energy  equal  to  one  watt-second. 

JUMPER/STRAP .  {11}  A  short  wire,  strip,  strap,  or  braid  conductor  installed  to 
make  a  safety  ground  connection,  to  dissipate  electrostatic  charge,  or  establish 
continuity  around  a  break  in  a  circuit. 

KILOBYTE.  {16}  One  thousand  bytes. 

KNOWLEDGE  ACQUISITION.  {20}  The  process  of  gathering  the  required  information 
from  various  sources  by  a  knowledge  engineer. 

KNOWLEDGE  BASE.  {20}  A  form  of  coded  knowledge  about  a  specific  domain. 

KNOWLEDGE-BASED  SYSTEM .  {20}  A  computer  system  whose  usefulness  derives 

primarily  from  a  database  containing  human  knowledge  in  a  computerized  format. 

KNOWLEDGE  ENGINEER.  {20}  The  person  responsible  for  extracting,  organizing,  and 
encoding  the  knowledge  related  to  the  problem,  and  importing  it  into  a  knowledge 
base  or  database. 

LABEL.  {20}  A  data  item  that  serves  to  identify  a  data  record,  or  a  symbolic 
name  used  in  a  program  to  mark  the  location  of  a  particular  instruction  or 
routine . 

LABELED  ADDRESSING.  {6}  The  system  of  identifying  message  recipients  based  on 
labels.  This  is  in  contrast  to  destination  terminal  addresses. 
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LATENT  FAULT.  (10)  A  fault  which  has  not  yet  produced  a  malfunction.  (In  the 
context  of  the  single— fault  model,  benign  and  latent  faults  are  equivalent.) 

LAYER.  (20)  A  row  of  neurons  in  a  Neural  Network;  there  are  usually  three  layers 
in  a  network. 

LIGHTNING  FLASH.  (13)  The  total  lightning  event  in  which  charge  is  transferred 
from  one  charge  center  to  another.  It  may  occur  within  a  cloud,  between  clouds, 
or  between  a  cloud  and  the  ground.  It  can  consist  of  one  or  more  strokes,  plus 
intermediate  or  continuing  currents. 

LIGHTNING  LEADER  STROKE.  (13)  The  leader  forms  an  ionized  path  for  charge  to  be 
channeled  towards  the  opposite  charge  center.  The  stepped  leader  travels  in  a 
series  of  short,  luminous  steps  prior  to  the  first  return  stroke.  The  dart 
leader  reionizes  the  return  stroke  path  in  one  luminous  step  prior  to  each 
subsequent  return  stroke  in  the  lightning  strike. 

LIGHTNING  RETURN  STROKE.  (13)  A  lightning  current  surge  that  occurs  when  the 
lightning  leader  makes  contact  with  the  ground  or  an  opposite  charge  center. 

LIGHTNING  STRIKE.  (13)  Any  attachment  of  the  lightning  flash  to  the  aircraft. 

LIGHTNING  STRIKE  ZONES .  (13)  Locations  on  the  aircraft  where  the  lightning  flash 
will  attach  or  where  substantial  amounts  of  electrical  current  may  be  conducted 
between  attachment  points.  The  location  of  these  zones  on  any  aircraft  is 
dependent  on  the  aircraft's  geometry  and  operational  factors  and  often  varies 
from  one  aircraft  to  another. 

LIMITING.  VOLTAGE /CURRENT.  (11)  Semiconductor  components,  diodes,  Transorb,  or 
filter  designed  to  clip  and  shunt  to  ground  an  applied  transient  or  steadystate 
voltage.  Used  to  protect  against  noise  frequencies,  faults,  lightning,  and 
inductive  switching  transients. 

LINE  REPIACEABLE  UNIT.  (18,19)  An  electronics  unit  that  is  made  to  be  replaced 
on  the  flight  line,  as  opposed  to  one  that  requires  the  aircraft  be  taken  to  the 
shop  for  repair. 

LINEAR  BUS .  (18)  A  bus  where  users  are  connected  to  the  medium;  one  on  each  end, 
with  the  rest  connected  in  between. 

LOGICAL  SUM.  (20)  The  final  unified  result  of  the  rule  processes  of  a  fuzzy 
system. 

LOW-PASS  FILTER.  (12)  An  electrical  circuit  which  allows  the  p  issage  of  low 
frequencies  and  prevents  the  passage  of  high  frequencies. 

MACHINE  LEARNING.  (20)  The  process  or  technique  by  which  a  device  modifies  its 
own  behavior  as  the  result  of  its  past  experience  and  performance. 

MAGNETIC  FIELD.  (11)  A  radiated,  low-impedance  field  having  lines  of  "flux"  or 
magnetomotive  force  associated  with  an  electrical  current. 
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MALFUNCTION.  {11}  Failure  or  degradation  in  performance  that  compromises  flight 
safety. 

MANCHESTER  II  MODULATION.  {18}  A  non-return  to  zero,  bipolar  modulation  of  a 
voltage  that  encodes  bits  based  on  the  zero-crossing  direction  of  the  signal. 

MEAN  AERODYNAMIC  CHORD  (also  mean  chord)  .  {4}  The  chord  of  an  airfoil  whose 

length  is  equal  to  the  area  of  the  airfoil  section  divided  by  the  span. 

MEAN  FAILURE  RATE.  {10}  A  measure  of  survivability  defined  as  the  reciprocal  of 
the  mean  time  to  system  failure. 

MESSAGE  STRUCTURE.  {6}  The  organization  of  both  protocol  and  data  information 
in  a  message. 

META-KNOWLEDGE .  {20}  Knowledge  that  reveals  details  about  the  system  knowledge. 
METRIC.  {17}  A  measure. 

MICRON.  {16}  One-millionth  of  a  meter. 

MISSED  ALARM.  {7}  The  failure  of  a  fault  detection  monitor  or  algorithm  to 
detect  a  fault  when  there  is  a  sensor  fault. 

MODEL .  {20}  A  mathematical  or  physical  system,  obeying  certain  specified 

conditions,  whose  behavior  is  used  to  understand  a  physical,  biological,  or 
social  system  to  which  it  is  analogous  in  some  way. 

MODELING .  {18}  Creating  a  system  of  mathematical  equations  that  formulate  all 
the  significant  behavior  of  a  system. 

MODULE.  {17}  A  unit  of  code  which  implements  a  function. 

MONITORABILITY .  {6}  The  capacity  of  the  protocol  to  be  viewed  passively  to  allow 
observation  of  the  dynamics  of  the  protocol. 

MONOLITHIC.  {19}  A  single  substrate  used  for  an  integrated  circuit. 

MONOTONIC  FUNCTION.  {17}  A  function  in  which  a  certain  change  in  the  measure 
always  represents  a  certain  change  in  the  property  being  measured,  where  either 
change  is  simply  an  increase  or  decrease  in  magnitude. 

MULTIPLE  BURST.  {13}  A  randomly  spaced  series  of  bursts  of  short  duration,  low 
amplitude  current  pulses,  with  each  pulse  characterized  by  rapidly  changing 
currents.  These  bursts  may  result  from  lightning  leader  progression  or  branching 
and  may  be  accompanied  by  or  superimposed  on  stroke  or  continuing  currents .  The 
multiple  bursts  appear  to  be  most  intense  at  the  time  of  initial  leader 
attachment  to  the  aircraft. 

MULTIPLE  STRIKE.  {13}  Two  or  more  lightning  strikes  during  a  single  flight. 
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MULTIPLE  STROKE.  {13}  Two  or  more  return  strokes  occurring  during  a  single 
lightning  flash. 

MULTIPLE  TRIP  MONITOR.  {7}  A  fault  detection  algorithm  which  declares  a  fault 
after  the  sensor  output  has  exceeded  a  predefined  threshold  N  times . 

MULTIVERSION  PROGRAMMING.  {18}  N-version  programming. 

N-VERSION  PROGRAMMING.  {18}  The  independent  coding  of  a  number,  N,  of  redundant 
computer  programs  that  are  run  concurrently  for  the  purpose  of  comparing  their 
outputs . 

NANOSECOND.  {16}  One-billionth  of  a  second. 

NEGATIVELY  STABILIZED.  {4}  Aircraft  design  in  which  the  point  of  effective  lift 
is  aft  of  the  center  of  gravity. 

NEMATIC.  {19}  A  liquid  crystal  phase  with  molecules  having  a  single  optical  axis 
in  line  with  an  applied  magnetic  field. 

NETWORK  CONTROL  STRATEGY.  {6}  The  solution  proposed  by  the  designer  in  address¬ 
ing  his  specific  problem  (design  flexibility). 

NEURAL  NETWORK.  {20}  A  system  modelled  after  the  brain,  used  to  solve  problems 
by  a  mapping  of  input  data  to  output  data. 

NEURO-FUZZY .  {20}  Integrating  a  Neural  Network  and  fuzzy  logic  to  solve 

problems . 

NEURON .  {20}  The  computational  element  in  a  Neural  Network.  A  neuron  computes 
the  weighted  sum  of  the  inputs  from  other  neurons  and  produces  an  output. 

NODE.  {20}  1.  Representation  of  an  object  that  is  related  to  other  objects  via 
connection  weights.  2.  The  part  of  a  Neural  Network  that  calculates  and 
processes  information. 

NOISE .  {11}  Conducted  or  radiated  emission  causing  circuit  upset,  performance 

disorder,  or  undesired  sound. 

NOISE.  {20}  Meaningless  or  erroneous  bits  that  must  be  ignored  or  removed  from 
a  signal,  especially  in  communication  channels. 

NON  REAL-TIME  LEARNING .  {20}  Learning  done  in  a  Neural  Network  before  attempting 
to  solve  application  problems . 

NONLINEARITY.  {20}  A  system  in  which  the  outputs  do  not  correspond  to  the  inputs 
in  a  direct  or  inversely  proportional  relationship. 

NUMERICAL  APERTURE.  {6}  The  angle  of  acceptance  of  light  from  a  light  source  for 
a  given  fiber  optic  cable. 

OBJECT  CODE.  {17}  The  translation  of  source  code  that  is  loaded  into  a  computer. 
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OBJECT-ORIENTED .  {20}  A  representation  form  for  knowledge  in  which  all 

properties  of  an  object  are  associated  by  the  outgoing  and  incoming  arcs  at  its 
node;  the  representation  is  geared  towards  manipulating  objects  as  independent 
pieces  of  knowledge. 

OBSERVER.  {7}  An  algorithm  which  models  physical  relationships  between  sensor 
data  and  uses  the  data  to  provide  fault  detection  for  one  or  more  sensors .  This 
is  also  known  as  a  Luenberger  observer  or  a  signal  blender. 

OPERANDS .  {17}  The  variables  or  constants  on  which  the  operators  act. 

OPERATORS .  {17}  Symbols  which  affect  the  value  or  ordering  of  operands. 

OPPORTUNISTIC  REASONING.  {20}  The  process  of  solving  problems  in  a  way  that  is 
not  uniform  or  predictable.  Opportunistic  reasoning  attempts  to  solve  the 
problem  in  the  best  possible  way  for  each  individual  situation.  Rules  fire  when 
they  are  appropriate,  without  a  priori  ordering. 

OPTIMIZING  COMPILER.  {17}  A  computer  program  which,  while  translating  source 
code  into  object  code,  removes  inefficiencies  from  the  code. 

OUTPUT  LAYER .  {20}  The  layer  of  neurons  in  a  Neural  Network  that  takes  the 

outputs  from  the  hidden  layer,  processes  them,  and  then  produces  the  output  of 
the  network. 

OVERHEAD .  {18}  The  message  timing  gaps,  control  bits,  and  error  detection  bits 
added  to  some  data  to  satisfy  the  data  bus  protocol. 

PARALLEL  PROCESSING.  {20}  Performing  many  different  calculations  simultaneously 

to  reach  one  conclusion  or  solution. 

PARAMETERIZATION  CAPABILITY.  {6}  A  measure  of  how  well  the  attributes  of  the 
protocol  can  be  described  by  parameters. 

PARITY.  {18}  An  error  detection  bit  added  to  a  data  word  based  on  whether  the 
number  of  "one"  bits  is  even  or  odd. 

PARTITIONED .  {18}  Colocated  hardware  or  software  functions  that  are  designed  so 
that  adverse  interactions  between  them  cannot  occur. 

PEAK  RATE  OF  RISE.  {13}  The  maximum  instantaneous  slope  of  the  waveform  as  it 
rises  to  its  maximum  value.  Mathematically,  the  peak  rate  of  rise  of  a  function, 
i(t) ,  may  be  expressed  as  the  maximum  of  d[i(t)]/dt. 

PETRI  NET.  {18}  A  state  analysis  diagram  that  tracks  the  status  of  the  state 
transition  conditions  of  a  state  machine. 

PHONEME .  {19}  The  smallest  elements  of  speech. 

PHOTOLITHOGRAPHY .  {19}  An  integrated  circuit  fabrication  technique  using 

photographically  produced  masks. 
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PIN  LEVEL  TEST,  {12}  An  EMC  test  in  which  voltage  or  current  is  applied  directly 
to  a  conductor  at  a  connector  pin. 

PIXEL.  {19}  The  smallest  picture  element  of  a  display. 

POINT-MASS  SIMULATION.  {4}  Same  as  state  variables  airplane  model  (q.v.). 

POLLING .  {18}  A  method  whereby  a  CPU  monitors  the  status  of  a  peripheral  by 

periodically  reading  its  status  signals. 

POLYNOMIAL  CODE .  {18}  A  sequence  of  bits  that  represents  the  coefficients  of 

each  term  in  a  polynomial. 

POSITIVELY  STABILIZED  AIRCRAFT.  {4}  Aircraft  design  in  which  the  effective  point 
of  lift  is  forward  of  the  center  of  gravity. 

PRECIPITATION  STATIC  (P-static) .  {11}  Electrostatic  discharge,  corona,  arcing, 
and  streamering,  steady  state  or  impulsive,  causing  circuit  upset,  receiver  noise 
or  component  damage . 

PREDICATE  CALCULUS .  {20}  A  formal  language  of  classical  logic  that  uses 

functions  and  predicates  to  describe  relations  between  individual  entities. 

PREDICATE/TRANSITION  NETWORK.  {4}  A  bipartite  graph  (a  type  of  linear  graph)  to 
model  concurrency  between  redundant  concurrent  events.  Basically  a  modified 
generalized  petri  net. 

PRIMARY  STATION.  {18}  An  intelligent  HDLC  protocol  user,  usually  used  to  manage 
the  access  of  other  bus  users  to  the  bus . 

PROBABILITY.  {20}  A  theory  dealing  with  the  uncertainty  that  results  from  random 
behavior.  Probability  is  defined  over  the  numeric  range  of  0  to  1. 

PROCESSING  ELEMENT.  {20}  The  part  of  the  Neural  Network  where  the  computations 
are  performed. 

PRODUCTION  RULES .  {20}  A  common  technique  for  representing  procedural  knowledge 
in  an  Artificial  Intelligence  system. 

PROGRAM .  {17}  A  detailed  set  of  instructions  for  accomplishing  some  purpose. 

PROPAGATION  DELAY.  {18}  The  time  it  takes  an  electrical  signal  to  travel  from 
its  source  to  its  destination. 

PROTOCOL.  {18}  The  set  of  rules  by  which  all  bus  users  must  abide  to  access  the 
bus  and  ensure  its  specified  operation. 

Q,  {12}  The  quality  factor  of  a  resonant  circuit  which  is  the  ratio  of  the 
energy  stored  to  the  power  dissipated  per  cycle. 
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fyiTADRTTPT.F.X  ARCHITECTURE.  {4}  The  use  of  four  separate  lanes  (or  channels)  of 
computer  redundancy.  Each  lane  can  fail  separately  providing  a  fail— operational 
capability  for  the  digital  flight-control  system. 

QUALITY  MEASURE.  (17)  A  repeatable,  monotonic  relationship  relating  measures  of 
objects  (a  set  of  numbers)  to  subjective  qualities. 

RADIATED  EMISSION  (RE) .  (11)  Electromagnetic  energy  transmitted  and  propagated 
in  space  usually  considered  as  audio  frequency  or  radio  frequency  noise. 

RADIO  FREQUENCY  (RF) .  (11)  Frequencies  in  the  electromagnetic  spectrum  used  for 
radio  communications  extending  from  kilohertz  to  gigahertz. 

RADIO  FREQUENCY  INTERFERENCE  (RFI) .  (11)  Electromagnetic  interference  in  the 

radio  frequency  range . 

RASTER.  (19)  A  pattern  of  parallel  electron  beam  scan  lines  used  for  uniform 
coverage  of  a  CRT  screen. 

REAL-TIME  T.F.ARNTNO.  (20)  Learning  done  in  a  Neural  Network  while  solving  an 
application  problem. 

RECONFIGURATION .  (6)  The  capacity  of  a  system  to  rearrange  or  reconnect  the 

system  elements  or  functions. 

RECONFIGURATION .  (18)  The  process  of  a  system  reassigning  which  hardware 

performs  a  particular  function. 

RECOVERY  BLOCK .  (18)  A  block  of  code  executed  upon  detection  of  a  fault  to 

recover  from  the  erroneous  condition  that  results. 

RECOVERY  CACHE.  (9)  The  location  used  to  preserve  input  values  until  the  outputs 
resulting  from  them  have  been  accepted. 

RECURSION.  (20)  A  technique  in  which  an  apparently  circular  process  is  used  to 
perform  an  iterative  process. 

REDUNDANCY  MANAGEMENT.  (7)  The  computer  processing  which  is  needed  to  implement 
fault  detection  and  isolation  algorithms. 

REFERENCE .  (11)  1.  Structure,  for  electronics,  shields,  power.  2.  A  grid  of 

wires,  solid  sheet,  or  foil.  3.  A  wire  from  circuit  to  grounding  block  or  case. 
4.  A  wire  from  circuit  to  structure.  5.  Shield  tie.  6.  Earth. 

REGISTER.  (18)  A  single  word  of  RAM  located  within  an  IC  controller  that  is  used 
for  transferring  data  and  control  information. 

RELAXED  STATIC  STABILITY  AIRCRAFT.  (4)  An  aircraft  whose  center  of  gravity  is 
behind  the  wing's  point  of  effective  lift. 

RELIABILITY  ANALYSIS.  (4)  A  means  of  determining  the  probability  of  failure  in 
a  system.  Military  flight-critical  systems  typically  are  required  to  have 
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reliability  levels  of  10  5  to  10  7 ,  whereas  civil  flight-critical  systems  have 
reliability  levels  of  10“9  or  less. 

REMOTE  TERMINAL.  {18}  The  BIU  portion  of  a  MIL-STD-1553  bus  user. 

RESONANCE .  {12}  Resonance  occurs  in  an  electrical  circuit  when  the  energy  stored 
in  the  inductance  is  equal  to  the  energy  stored  in  the  capacitance. 

RETURN.  {11}  1.  Structure,  for  power,  fault,  and  "discrete"  circuits.  2.  A  grid 

of  wires,  solid  sheet,  or  foil.  3.  A  wire  from  circuit  load  back  to  source  or 
to  case.  4.  Circuit  card  "ground  plane,"  also  a  reference  and  shield. 

RETURN  STROKE .  {13}  See  lightning  return  stroke. 

REVERSION  MODE.  {7}  The  high  level  of  redundancy  in  a  system  having  different 
redundancy  requirements  for  some  sensors.  Critical  sensors  may  have  a  high  level 
of  redundancy  while  other  sensors  have  low  levels. 

RING  BUS .  {18}  A  bus  where  users  are  connected  only  to  the  two  adjacent  users 
in  a  continuous  ring;  each  connected  to  the  next  and  the  last  one  connected  to 
the  first  one. 

RISE-TIME.  {12}  The  time  required  for  a  voltage  pulse  to  reach  a  predefined 
magnitude  from  a  given  level. 

ROBUSTNESS .  {9}  The  ability  of  the  code  to  perform  despite  some  violation  of  the 
assumptions  in  its  specifications  usually  via  substitution  of  an  alternate  value 
and  continuation  of  execution  if  a  software  fault  is  detected. 

ROLLBACK .  {9}  Retrying  the  calculation  in  the  event  that  a  failure  is  detected, 
under  the  assumption  that  some  external  condition  may  have  changed  thereby 
resolving  the  anomaly. 

RULE-BASED .  {20}  An  Artificial  Intelligence  program  where  knowledge  is 

represented  as  rules. 

RULES .  {20}  A  method  of  representing  knowledge  in  the  form  of  IF  THEN 

statements . 

SCHEDULER.  {20}  A  part  of  an  inference  engine  that  determines  which  knowledge 
source  should  be  activated,  and  in  what  order. 

SEALANT .  {11}  An  applied  substance  enclosing  and  protecting  the  integrity  of  a 
joint,  fastener,  or  electrical  bond  from  moisture,  contaminants,  oxidation,  and 
acid  or  alkaline  corrosion. 

SEARCH  TREE.  {20}  The  branches  of  possible  solutions  to  a  problem  that  start 
with  initial  information  and  spread  out  following  different  paths. 

SECONDARY  STATION.  {18}  A  simple  HDLC  protocol  user. 
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SELF— SUPERVISED .  {20}  A  method  of  training  a  Neural  Network  without  the  use  of 
an  external  monitor.  A  feedback  device  that  detects  errors  and  adjusts  the 
connection  weights  accordingly  is  used. 

SEMANTIC  NETWORK.  {20}  A  method  of  representing  knowledge  using  nodes  and  arcs. 

SENSOR.  {7}  An  instrument  which  measures  a  particular  physical  parameter.  The 
data  output  may  be  digital  or  analog  and  is  utilized  by  the  flight  computer. 

SENSOR.  {18,19}  Any  transducer  that  converts  the  measurement  of  a  physical 
quantity  to  an  electrical  signal. 

SEQUENTIAL  LIKELIHOOD  RATIO  TEST.  {7}  A  fault  detection  algorithm  which  is  based 
on  two  hypothesized  density  functions  of  no  fault  or  sensor  fault. 

SEQUENTIAL  PROBABILITY  RATIO  TEST.  {7}  See  sequential  likelihood  ratio  test. 

SERIAL  DATA  BUS.  {18}  A  data  bus  capable  of  sending  only  one  bit  at  a  time,  in 
series . 

SERVICE  SPECIFICATION .  {18}  The  specification  of  the  service  provided  by  a 

protocol  layer. 

SHIELD .  {11}  A  conductive  material,  opaque  to  electromagnetic  energy,  for 
confining  or  repelling  electromagnetic  fields.  A  structure,  skin  panel,  case, 
cover,  liner,  foil,  coating,  braid,  or  cable-way  that  reduces  electric  and 
magnetic  fields  into  or  out  of  circuits  or  prevents  accidental  contact  with 
hazardous  voltages . 

SHIELD  EFFECTIVENESS  (SE) .  {11}  The  ability  of  a  shield  to  reject  electro¬ 

magnetic  fields.  A  measure  of  attenuation  in  field  strength  at  a  point  in  space 
caused  by  the  insertion  of  a  shield  between  the  source  and  the  point. 

SHIELDING .  {12}  Any  metallic  structure  such  as  the  aircraft  fuselage  or  the 

woven  braid  on  a  cable  that  provides  protection  against  electromagnetic  fields. 

SIGNAL  RETURN.  {11}  A  wire  conductor  between  a  load  and  the  signal  or  driving 
source.  Structure  can  be  a  signal  and  power  return.  Commonly,  it  is  the  low 
voltage  side  of  the  closed  loop  energy  transfer  circuit. 

SIMULATION.  {18,19}  An  approximated  representation  of  the  behavior  of  a  system 
with  a  similar  system. 

SINGLE-ENDED  CIRCUIT.  {11}  A  circuit  with  source  and  load  ends  grounded  to  case 
and  structure  and  using  structure  as  return. 

SINGLE-POINT  FAILURE.  {18}  A  failure  of  a  component  that,  by  itself,  causes  the 
failure  of  the  system  in  which  it  is  contained. 

SINUSOID .  {12}  A  wave  form  that  follows  the  mathematical  values  of  a  sine 

function. 
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SLOTS .  {20}  Subdivisions  making  up  the  frame  that  may  contain  data,  procedures, 
or  pointers  to  other  frames. 

SMECTIC .  {19}  A  liquid  crystal  phase  with  molecules  arranged  in  layers. 

SOFT  FAILURE.  {12}  A  failure  which  causes  an  alteration  of  data  or  missing  data. 

SOFTWARE .  {17}  Computer  programs  and  the  documentation  associated  with  the 

programs . 

SOFTWARE  METRIC.  {17}  A  measure  of  software  objects. 

SOFTWARE  QUALITY  FACTOR.  {17}  Any  software  attribute  that  contributes  either 
directly  or  indirectly,  positively  or  negatively,  toward  the  objectives  for  the 
system  in  which  the  software  resides. 

SOFTWARE  QUALITY  METRIC.  {17}  (1)  A  measure  that  relates  measures  of  the 

software  objects  (the  symbols)  to  the  software  qualities  (quality  factors).  (2) 
The  measure  of  a  software  quality  factor. 

SOURCE  CODE.  {17}  Code  that  can  be  read  by  people. 

SPECIAL  CONDITION.  {18}  A  regulatory  document  that  adds  to,  or  otherwise  alters, 
the  airworthiness  standards  for  particular  aircraft. 

SPURIOUS  STATE.  {20}  A  point  in  a  Neural  Network  that  acts  as  an  attractor,  but 
is  not  one  of  the  stored  patterns. 

STABILITY.  {20}  The  property  of  a  system  which  remains  under  control  and 
responds  in  a  reasonable  manner  to  an  applied  input. 

STATE-VARIABLE  AIRPLANE  MODEL  (also  point-mass  model).  {4}  Fixed  aerodynamic 
variables  are  used  in  the  solution  of  the  equations  of  motion  of  the  model 
instead  of  using  look-up  tables  in  which  each  derivative  varies  with  airspeed, 
altitude,  etc.  The  model  performance  is  only  accurate  at  or  near  the  point  in 
the  flight  envelope  for  which  the  variables  are  chosen. 

STATIC  MARGIN.  {4}  The  degree  of  instability  in  a  relaxed  statically  stable 
airplane . 

STATION.  {18}  Bus  user. 

STATIONARY  BUS  CONTROL.  {18}  Bus  control  that  is  continually  performed  by  a 
single  bus  controller,  or  by  one  of  its  backups. 

STATUS  REGISTER.  {18}  A  register  in  an  IC  controller  that  holds  the  status  of 
the  state  of  certain  controller  functions. 

STROKE.  {19}  A  nonuniform  technique  of  CRT  screen  refresh  using  penlike  control 
of  the  electron  beam. 
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STROUD  NUMBER.  {17}  The  total  number  of  elementary  mental  discriminations  that 
a  person  makes  per  second. 

STRUCTURAL  IR  VOLTAGE.  {13}  The  portion  of  the  induced  voltage  resulting  from 
the  product  of  the  distributed  lightning  current,  1,  flowing  through  the 
resistance,  R,  of  the  aircraft  skin  or  structure. 

STRUCTURE .  {11}  Basic  members,  supports,  spars,  stanchions,  housing,  skin 
panels,  or  coverings  that  may  or  may  not  provide  conductive  return  paths  and 
shields  for  electrical/electronic  circuits. 

STUB.  {18}  The  short  length  of  cable  used  to  attach  a  single  LRU  to  a  data  bus. 

SUBROUTINE .  {17}  A  self-contained  body  of  code  which  can  be  called  by  other 
routines  to  perform  a  function. 

SUPER-DIAGNOSTIC  FILTER.  {7}  An  algorithm  which  provides  all  the  capabilities 
of  a  diagnostic  filter.  Additionally,  it  can  isolate  a  specific  faulted  sensor. 
At  the  current  time,  this  is  the  most  complex  technique  used  to  implement 
analytical  redundancy. 

SUPERVISED  LEARNING.  {20}  A  method  of  training  a  Neural  Network  in  which  an 
external  supervisor  monitors  the  activities,  and  learning  occurs  on  the  basis  of 
direct  comparison  of  the  output  of  the  network  with  known  correct  answers, 

SUSCEPTIBILITY.  {11}  Upset  behavior  or  characteristic  response  of  an  equipment 
when  subjected  to  specified  electromagnetic  energy.  Identified  with  the  point, 
threshold,  or  onset  of  operation  outside  of  performance  limits.  Conducted 
Susceptibility  (CS)  applies  to  energy  on  interface  conductors;  Radiated 
Susceptibility  (RS)  to  radiated  fields. 

SWEPT  STROKE.  {13}  A  series  of  successive  attachments  due  to  sweeping  of  the 
flash  across  the  surface  of  the  airplane  by  the  motion  of  the  airplane. 

SYMBOLIC  PROCESSING .  {20}  A  method  of  processing  knowledge  where  the 
relationships  among  the  knowledge  are  stored  using  symbolic  representations, 
thus,  the  system  can  deal  freely  with  objects  and  not  be  concerned  with  their 
composition. 

SYNAPSES .  {20}  Pathways  in  a  biological  neuron  that  transmit  pulses  from  one 
neuron  to  another. 

SYNCHRONOUS .  {20}  In  step,  or  in  phase,  as  applied  to  two  or  more  circuits, 
devices ,  or  machines . 

SYNCHRONOUS  MESSAGES.  (6)  Messages  transmitted  at  a  known  a  priori  sequence  and 
time  or  time  interval. 

SYSTEM  EXPOSURE  TIME.  {4}  The  period  during  which  a  system  may  fail.  This 
period  extends  from  the  last  verified  proper  functioning  to  the  completion  of  the 
next  required  performance. 
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SYSTEM  FUNCTIONAL  UPSET.  (13)  Impairment  of  system  operation,  whether  permanent 
or  momentary  (e.g.,  a  change  of  digital  or  analog  state)  which  may  or  may  not 
require  manual  reset. 

SYSTEM  INTEGRATOR.  (18)  The  developer  who  has  the  responsibility  to  integrate 
the  various  subsystems  into  a  working  system. 

SYSTEM  INTEGRITY.  (6)  The  degree  to  which  a  system  is  dependable. 

SYSTEM  RELIABILITY.  (5)  The  probability  of  performing  a  given  function  from  the 
some  initial  time,  t=0 ,  to  time  t. 

TESTABILITY.  (6)  A  measure  of  how  well  the  protocol  supports  completeness  of 
testing  and  the  protocol's  ability  to  produce  repeatable  or  predictable  results. 

THRESHOLD.  NOISE.  (11)  The  lowest  electromagnetic  interference  signal  level  that 
produces  onset  of  susceptibility. 

THROUGHPUT .  (6)  The  productivity  of  a  data  processing  system  as  expressed  in 

computing  work  per  minute  or  hour. 

THYRISTORS.  (16)  Solid-state  devices  that  convert  alternating  current  to  direct 
current . 

TIME  CONSTANT.  (4)  Time  required  to  double  the  amplitude  of  the  divergent  real 
root  in  the  pitch  axis  of  the  aircraft  model. 

TOKEN  PASSING  PROTOCOL.  (18)  A  protocol  that  limits  bus  access  to  the  user  that 
has  just  received  the  token  word. 

TRADITIONAL  PROGRAMMING.  (20)  The  use  of  standard  programming  languages,  as 
opposed  to  application  development  languages,  financial  planning  languages,  query 
languages,  and  report  programs. 

TRAINING .  (20)  A  change  in  connection  weight  values  of  a  Neural  Network  that 

results  in  capturing  information  that  can  be  recalled  later. 

TRANSFER  FUNCTION.  (20)  The  mathematical  relationship  between  the  output  of  a 
control  system  and  its  input:  for  a  linear  system,  it  is  the  Laplace  transform 
of  the  output  divided  by  the  Laplace  transform  of  the  input  under  conditions  of 
zero  initial-energy  storage. 

TRANSIENT  CONTROL  LEVEL.  {13}  The  maximum  allowable  level  of  transients  appear¬ 
ing  at  the  systems  interfaces  as  a  result  of  the  defined  external  environment. 

TRANSPARENCY.  (20)  A  characteristic  of  knowledge  in  an  Expert  System  referring 
to  its  independence  from  other  knowledge.  There  is  no  processing  information  in 
the  transparent  knowledge . 

TRANSPARENT  RECOVERY.  (4)  Correcting  a  soft  fault  without  interrupting  the 
system's  intended  performance. 
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TRANSPORT  AIRCRAFT.  {19}  Aircraft  used  in  interstate,  overseas,  or  foreign  air 
transportation . 

TRIBOELECTRIC  CHARGING.  {13}  Static  electricity  produced  on  a  structure  from  the 
effects  of  friction. 

UNACCEPTABLE  RESPONSE.  {11}  Upset,  degradation  of  performance,  or  failure,  not 
designated  a  malfunction,  but  is  detrimental  or  compromising  to  cost,  schedule, 
comfort,  or  workload. 

UNBALANCED  CONFIGURATION.  {18}  A  bus  using  the  HDLC  protocol  that  connects  one 
primary  and  one  or  more  secondary  stations. 

UNDESIRABLE  RESPONSE.  {11}  Change  of  performance  and  output,  not  designated  a 
malfunction  or  safety  hazard,  that  is  evaluated  as  acceptable  as  is  because  of 
minimum  nuisance  effects  and  excessive  cost  burdens  to  correct. 

UNIDIRECTIONAL  DATA  BUS.  {18}  A  data  bus  with  only  one  user  that  Is  capable  of 
transmitting. 

UNSUPERVISED  LEARNING.  {20}  A  method  of  training  a  Neural  Network,  where  no 
external  monitor  is  involved;  the  Neural  Network  organizes  itself  by  grouping  and 
generating  its  own  classification  of  inputs. 

UPSET .  {11}  Temporary  interruption  of  performance  that  is  self-correcting  or 
reversible  by  manual  or  automatic  process. 

UPSET.  {12}  A  condition  in  which  the  state  of  a  digital  device  is  uninten¬ 
tionally  altered,  but  may  be  restored  by  automatic  means  or  by  operator 
intervention. 

UPSET .  {13}  See  system  functional  upset. 

VALIDATION.  {4,11}  Demonstration  and  authentication  that  a  final  product 
operates  in  all  modes  and  performs  consistently  and  successfully  under  all  actual 
operational  and  environmental  conditions  founded  upon  conformance  to  the 
applicable  specifications . 

VALIDATION.  {18}  The  process  of  evaluating  whether  or  not  items,  processes, 
services,  or  documents  accomplish  their  intended  purpose  in  their  operating 
environment . 

VERIFICATION.  {4,11}  Demonstration  by  similarity,  previous  in-service 
experience,  analysis,  measurement,  or  operation  that  the  performance, 
characteristics ,  or  parameters  of  equipment  and  parts  demonstrate  accuracy ,  show 
the  quality  of  being  repeatable,  and  meet  or  are  acceptable  under  applicable 
specifications . 

VERIFICATION.  {18}  The  act  of  reviewing,  inspecting,  testing,  checking, 
auditing,  or  otherwise  establishing  and  documenting  whether  or  not  items, 
processes,  services,  or  documents  conform  to  specified  requirements. 
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VERY  LARGE  SCALE  INTEGRATION.  {20}  Describing  Integrated  Circuits  with  more  than 
1000  elements. 

VOTING  PROCEDURE.  {8}  An  algorithm  included  in  fault  tolerant  software  which 
uses  the  consensus  recovery  block  method.  It  compares  outputs  of  the  n 
independent  versions  and  determines  which  outputs  are  correct  by  identifying 
agreements  among  two  or  more  versions. 

WEIGHT  MATRIX.  {20}  The  collection  of  connection  weights  for  an  entire  Neural 
Network. 

WELL-BEHAVED  FUNCTION .  {17}  A  smooth  mathematical  relationship. 
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ACRONYMS  AND  ABBREVIATIONS 


A  (17} 

/iC 

/im  {6,20} 
^  (18) 
r?  (17) 
fli  U7) 

•11*  117} 
r?2  U7} 
r)2  (17) 

<f>M  { 6 } 
1/E0  (17) 


3-D  {16} 


Language  Level 
micro  Controller 
Micrometer 
Microsecond 

Vocabulary  of  a  Program 
Number  of  Unique  Operators 
Minimum  Number  of  Unique  Operators 
Number  of  Unique  Operands 

Number  of  Different  Input  and  Output  Parameters 
Phase  Modulation 

Average  number  of  discriminations  a  person  is 
likely  to  make  for  each  bug  introduced  into  the 
code . 

Three-Dimensional 


A/C  {11} 

A/L  {3} 

A3I  {19} 

AAES  {15} 

ABET  {19} 
ac  {3,6,12,15,19} 

AC  {3,5,14,17,18,19,20} 
ACAP  {13} 

ACARS  {11,12} 

ACES  {13} 

ACK  {18} 

ACO  {18,20} 

ACS  {16} 

ACT  {11,12} 

ACT  {17} 

AD  (19) 

ADC  {11,12} 

ADF  {11,12,19} 

ADI  {3} 

AE  {6} 

AE4L  {5,13} 

AEEC  {18} 

AEHP  {13} 

AERA  {16} 

AES-S  {6} 

AF  (11,12) 

AFBW  {4} 

AFCS  {11,12} 

AFFDL  {7,8,13} 


Aircraft 

Approach/Land 

Army-NASA  Aircrew/Aircraft  Integration 
Advanced  Aircraft  Electrical  System 
Aerospace  Behavioral  Engineering  Technology 
Alternating  Current 
Advisory  Circular 

Advanced  Composite  Airframe  Program 

ARC  Communications  Addressing  and  Reporting 

System 

Applied  Computational  Electromagnetics  Society 
Acknowledge 

Aircraft  Certification  Office 
Automatic  Control  System 
Active  Controls  Technology 
Analysis  of  Complexity  Tool 
Alerting  Display 
Air  Data  Computer 
Automatic  Direction  Finder 
Automatic  Direction  Indicator 
Avionics  Equipment 
SAE  Subcommittee  (Lightning) 

Airlines  Electronic  Engineering  Committee 
Atmospheric  Electricity  Hazards  Protection 
Automated  En  Route  Air  Traffic  Control  System 
Aerospace  and  Electronic  Systems  Society 
Audio  Frequency 
Augmented  Fly-By-Wire 
Automatic  Flight  Control  System 
Air  Force  Flight  Dynamics  Laboratory 
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AFM  {16} 

AFSC  {18} 

AFWAL  {6,13} 

AGARD  {8,20} 

AHRS  {6} 

AI  {16,19,20} 

AIAA  {5,6,9,15,18,20} 

AIM  {18} 

AIM  {20} 

AIR  {18,19} 

AIRLAB  {5,18} 

AK  {7} 

ALCM  {13} 

ALPA  {19} 

ALU  {3,5,10} 

AM  {19} 

AM  {6,14} 

AM  {5} 

AMS  {19} 

AMSC  {5} 

ANSI  (11,12,20) 

AOA  (4) 

AP  (18) 

APU  {11,12,15} 

AR  {7} 

ARC  (11,12) 

ARIES  {3} 

ARINC  {3,6,18,20} 

ARP  {17,18,19,20} 
ARPA  {20} 

ARTERI  {15} 

AS  {19} 

ASCB  {6,18} 

ASDS  {11,12} 

ASEE  {5,15} 

ASIC  {20} 

ASME  {5} 

ASRS  {19} 

ATC  {19,20} 

ATCRBS  {11,12,14} 

ATE  {20} 

ATF  (16) 

ATI  {16} 

ATTR  {5} 

AWACS  {14} 


Advanced  Fuel  Management 

Air  Force  Systems  Command 

Air  Force  Wright  Aeronautical  Laboratory 

Advisory  Group  for  Aerospace  Research  and 

Development 

Attitude  Heading  Reference  System 

Artificial  Intelligence 

American  Institute  of  Aeronautics  and 

Astronautics 

Advanced  Integrated  MUX 

Airmen's  Information  Manual 

Aerospace  Information  Report 

Avionics  Integration  Research  Laboratory 

Altitude  Kinematics 

Air  Launched  Cruise  Missile 

Air  Line  Pilot's  Association 

Arithmetic  Logic  Unit 

Active-Matrix 

Amplitude  Modulation 

Amplitude  Modulated 

Aerospace  Material  Specification 

Document  number  prefix  used  by  the  Department  of 
Defense 

American  National  Standards  Institute 

Angle  of  Attack 

Application  Processor 

Auxiliary  Power  Unit 

Analytical  Redundancy 

Aeronautical  Radio,  Incorporated 

Automated  Reliability  Interactive  Estimation 

System 

Aeronautical  Radio,  Incorporated 
Aerospace  Recommended  Practice 
Advanced  Research  Projects  Agency  (formerly 
DARPA) 

Analytical  Redundancy  Technology  for  Engine 
Reliability  Improvement 
Aerospace  Standard 

Avionics  Standard  Communications  Bus 
Airport  Surface  Detection  System 
American  Society  of  Electrical  Engineers 
Application  Specific  Integrated  Circuit 
American  Society  of  Mechanical  Engineers 
Aviation  Safety  Reporting  System 
Air  Traffic  Control 

Air  Traffic  Control  Radar  Beacon  System 

Automatic  Test  Equipment 

Advanced  Tactical  Fighter 

Access  Time  Interval 

Attribute 

Airborne  Warning  and  Control  System 
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B  {17} 

B— dot  {13} 

B-GLOSS  {5} 

BABBAGE  {20} 

BAC  {18} 

BAT  {17} 

BB  {11,12} 

BC  {18} 

BCAC  {18} 

BCD  {18} 

BCI  {12} 

BFCS  {18} 

BGU  {10} 

BIR  {6} 

BIT  {6,15,18,20} 
BITE  {6,11,12,19} 
BIU  {6,18} 

BNR  {18} 

BOCP  {18} 

BP  {18} 
bps  {6} 

BUSY  {18} 

BW  {11,12} 


Number  of  Bugs  (Estimated) 

Derivative  of  the  magnetic  field  with  respect  to 
time 

Gate  Logic  Software  Simulator  developed  by 
Bendix 

Boeing  Advanced  Blackboard  Ada  Generation 
Environment 

Balanced  Asynchronous  Configuration 

Battlemap  Analysis  Tool 

Broadband 

Bus  Controller 

Boeing  Commercial  Airplane  Company 

Binary  Coded  Decimal 

Bulk  Cable  Injection 

Beacon  Frame  Check  Sequence 

Bus  Guardian  Unit 

Benchmark  Information  Rate 

Built-In  Test 

Built-In  Test  Equipment 

Bus  Interface  Unit 

Binary 

Bit-Oriented  Communications  Protocol 

Basic  Protocol 

bits  per  second 

Destination  Busy 

Bandwidth 


C/I  (5) 

Communicator  Interstage 

C  (7) 

Comparator 

CA  (18) 

Criticality  Analysis 

CAA  (14,19} 

Civil  Aviation  Authority 

CAD  {5,19} 

Computer  Aided  Design 

CALSEL  (19} 

Call  Select 

CAP  (5} 

Collins  Application  Processor 

CAPS  (3) 

Computer  Aided  Production  Simulator 

CARE  (3,5) 

Computer  Aided  Reliability  Evaluator 

CARSRA  (3,7) 

Computer-Aided  Redundant  System  Reliability 
Analysis 

CAS  {11,12} 

Criticality  Advisory  System 

CASSY  (20) 

Cockpit  Assistant  System 

CAST  (3) 

Complementary  Analytic  Simulative  Technique 

CBD  (5) 

Commerce  Business  Daily 

CBI  (19) 

Computer  Based  Instruction 

CCITT  (6) 

Consultative  Committee  for  International 
Telephone  and  Telegraph 

CD  (6) 

Collision  Detection 

cdf  (8) 

Cumulative  Density  Function 

CDU  (11,12,19,20) 

Control  Display  Unit 

CE  (11,12) 

Conducted  Emission 

CE  {17,18,19,20} 

Certification  Engineer 

CF  (20) 

Certainty  Factor 

CFR  {17,19} 

Code  of  Federal  Regulations 
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cm  (19) 

CM  {20} 

CM  {11,12} 

CMC  {18} 

CMOS  {5,12,20} 

CMU  {19} 

CNI  {20} 

COMBIMAN  {19} 

CONUS  {14} 

CP  {18} 

CPA  {5} 

CPU  {5,10,18,19,20} 
CR  {5} 

CR  {6} 

CR/LF  {17} 

CRC  {6,18} 

CRM  {19} 

CRMI  {2} 

CRT  {11,12,16,19} 

CS  {11,12} 

CSC  {9} 

CSCI  {9,17} 

CSDB  {18} 

CSDL  {5,10,15} 
CSERIAC  {19} 

CSMA  {6,16,18} 
CSMA/CD  {6} 

CT  {2,6} 

CTA  {3} 

CTA  {5} 

CTS  {18} 

CW  {13} 


Centimeter 

Configuration  Management 

Common  Mode 

Current  Mode  Coupler 

Complimentary  Metal-Oxide  Semiconductor 
Computer  Mock-Up 

Communication,  Navigation,  and  Identification 

Computerized  Biomechanical  Man-model 

Contiguous  United  States 

Combined  Protocol 

Central  Processor  -  A 

Central  Processing  Unit 

Contractor  Report 

Command  Response 

Carriage  Return/Line  Feed 

Cyclic  Redundancy  Check 

Cockpit  Resource  Management  (also  Crew  Resource 
Management) 

Computer  Resource  Management,  Incorporated 

Cathode  Ray  Tube 

Conducted  Susceptibility 

Computer  Software  Component 

Computer  Software  Configuration  Item 

Commercial  Standard  Data  Bus 

Charles  Stark  Draper  Laboratories 

Crew  System  Ergonomics  Information  Analysis 

Center 

Carrier  Sensed  Multiple  Access 

Carrier  Sense  Multiple  Access/Collision 

Detection 

Technical  Center  (designation  used  in  FAA  report 
numbering  scheme) 

CAPS  Test  Adapter 
Collins  Test  Adaptor 
Clear  To  Send 
Continuous  Wave 


D  {17} 

DADC  {6} 

DARPA  {16} 

DATAC  {6,18} 
dB  (6,12) 
dBi  {14} 
dBm  { 6 } 

dc  {6,12,15,19} 
DC  {18} 

DE  {5} 

DEFN  {5} 

DEP  {19} 

DET  {18} 

DEV  {5} 


Program  Difficulty 
Digital  Air  Data  Computer 

Defense  Advanced  Research  Projects  Agency  (Now 
known  as  Advanced  Research  Projects  Agency) 
Digital  Autonomous  Terminal  Access  Communication 
Decibel 

Decibels  with  respect  to  one  milliampere 

Decibels  with  respect  to  one  milliwatt 

Direct  Current 

Display  Computer 

Diagnostic  Emulation 

Definition 

Design  Eye  Position 

Driver  Enable  Timer 

Development 
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DF  (7) 

Diagnostic  Filter 

DFC  {7} 

Digital  Flight  Control 

DFCS  {3,4,7,16} 

Digital  Flight  Control  System 

DFDAU  {11,12} 

Digital  Flight  Data  Acquisition  Unit 

DFDR  {11,12} 

Digital  Flight  Data  Recorder 

DGAC  {14} 

Directorate  Generale  Aviation  Civile 

DISAC  {15} 

Digital  Integrated  Servo  Actuator  Controller 

DITS  {6,11,12,18} 

Digital  Information  Transfer  System 

DM  {11} 

Differential  Mode 

DM  {6} 

Delay  Modulation 

DMA  {5,6} 

Direct  Memory  Access 

DMA  {18} 

Direct  Memory  Addressing 

DME  {11,12,18,19} 

Distance  Measuring  Equipment 

DNA  {13} 

Defense  Nuclear  Agency 

DoD  (5,8,12,14,16,19,20) 

Department  of  Defense 

DOE  {13} 

Department  of  Energy 

DOS  (20) 

Disk  Operating  System 

DOT  {2,3,6,7,8,20} 

Department  of  Transportation 

DR  {17} 

Direct  Ratio  (Average) 

DRB  {9} 

Distributed  Recovery  Block 

DS  {17} 

Direct  Score 

DSP  {3} 

Discrete  Switch  Panel 

DSP  {20} 

Digital  Signal  Processor 

DTSA  {18} 

Dynamic  Time  Slot  Allocation 

E/E  {11,12} 

Electrical/Electronic 

E-FIELD  {11,12} 

Electric  Field 

E  (17) 

Programming  Effort 

E-dot  (13) 

Derivative  of  the  electric  field  with  respect  to 
time 

E3  (11,12} 

Electromagnetic  Environmental  Effects 

EADI  (11,12,19) 

Electronic  Attitude  Director  Indicator 

ECAC  (11,12,14) 

Electromagnetic  Compatibility  Analysis  Center 

ECM  {14} 

Electronic  Counter  Measures 

ECS  {11,12} 

Environmental  Control  System 

EEC  {5,11,12,18} 

Electronic  Engine  Control 

EED  {11,12} 

Electro-Explosive  Device 

EEPROM  {20} 

Electrically  Erasable  Programmable  Read  Only 
Memory 

EES  {18} 

Electromagnetic  Emission  and  Susceptibility 

EFID  {18} 

Electronic  Flight  Instrument  Display 

EFIS  {11,12,18,19} 

Electronic  Flight  Instrument  System 

EFMA  {3} 

Executive  Failure  My  A 

EFMB  {3} 

Executive  Failure  My  B 

EFOA  {3} 

Executive  Failure  Other  A 

EFOB  {3} 

Executive  Failure  Other  B 

EFW  {3} 

Executive  Failure  Word 

Eg  (19) 

Energy  gap 

EGT  (11,12) 

Exhaust  Gas  Temperature 

EHSI  {11,12} 

Electronic  Horizontal  Situation  Indicator 

EIA  {18} 

Electronic  Industries  Association 

EICAS  {11,12} 

Engine  Indication  and  Crew  Alerting  System 
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EIU  {16} 

EL  (19) 

ELS  {19} 

EM  {5,11.12,13} 

EMA  {15} 

EMAS  {2,15} 

EMC  {6,11,12,13,14} 
EMCadtm  {12} 

EME  {14} 

EME  {11,12} 

EMI  {5,6,11,12,13,15,16} 
EMIC  {11,12} 

EMP  {11,12,13} 

EMR  {5,14} 

EMUX  {6} 

ENRZ  {6} 

EOF  {17} 

EPES  {20} 

EPR  {11,12,15} 

EPROM  {16} 

ES  {20} 

ESD  {11,12} 

ESE  {11,12} 

ESS  {5,9} 

ETANN  {20} 

ETDL  {13} 

EUROCAE  {14} 

EVS  {19} 

EXCHNG  {5} 

EXP  {5} 


Electronic  Interface  Unit 
Electroluminescent 
Electronic  Library  System 
Electromagnetic 
Electromechanical  Actuator 
Electromechanical  Actuator  System 
Electromagnetic  Compatibility 
Electromagnetic  Computer  aided  design 
Electromagnetic  Environment 
Electromagnetic  Effects 
Electromagnetic  Interference 

Electromagnetic  Interference/Compatibility 

Electromagnetic  Pulse 

Electromagnetic  Radiation 

Electrical  Multiplex 

Enhanced  Non— Return  to  Zero 

End  of  File 

Emergency  Procedures  Expert  System 
Engine  Pressure  Ratio 

Erasable  Programmable  Read-Only  Memory 
Expert  System 
Electrostatic  Discharge 
Electric  (field)  Shield  Effectiveness 
Electronic  Switching  System 

Electrically  Trainable  Analog  Neural  Network 
Equipment  Transient  Design  Level 
European  Organization  for  Civil  Aviation 
Electronics 

Enhanced  Vision  System 

Exchange 

Experiment 


F/FA  {18,20} 

FAA  {ALL} 

FADEC  {6,15,16} 
FAFTEEC  {16} 

FAR  {17,18,19,20} 
FAR  {3,4,6,16} 

FAS  {19} 

FBL  {15,16} 

FBW  {4,7,16} 

FCA  {20} 

FCC  {3,4,5,6,10,11, 
12,15,18,19} 
FCR  {5} 

FCS  {18} 

FCS  {4,5,10,16} 

FD  {7} 

FDEP  {11,12} 

FDFM  {15} 

FDI  {19} 


Fault  and  Failure  Analysis 

Federal  Aviation  Administration 

Full  Authority  Digital  Engine  Controller 

Full  Authority  Fault  Tolerant  Electronic  Engine 

Control 

Federal  Aviation  Regulation 
Federal  Acquisition  Regulation 
Flight  Deck  Alerting  System 
Fly-By-Light 
Fly— By— Wire 

Fuzzy  Computational  Accelerator 
Flight  Control  Computer 

Fault  Containment  Regions 
Frame  Check  Sequence 
Flight  Control  System 
Fault  Detection 
Flight  Data  Entry  Panel 

Fault  Detection  and  Failure  Management 
Flight  Director  Indicator 
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FET  (5,16,19) 
FI  (7) 

FI  (5) 

FIAT  (5) 

FICA  (15) 

FIDE  (20) 

FIIS  (5,10) 

FIL  (20) 

FIM  (5) 

FINDER  (20) 

FIRE  (5) 

FLEX  (20) 

FM  (5) 

FM  (6,14) 

FMC  (11,12,19) 
FMEA  (3,9,18) 
FMECA  (5,15) 
FMECA  (18) 

FMS  (19) 

FOV  (19) 

FP  (17) 

FSM  (18) 
ft  (14) 

FT  (5) 

FTA  (18) 

FTC  (5) 

FTMP  (5,10,18) 
FTP  (5) 


Field  Effect  Transistor 

Fault  Isolation 

Fault  Insertion  Circuitry 

Fault  Injection  Automated  Testing 

Failure  Indication  and  Corrective  Action 

Fuzzy  Inference  Development  Environment 

Fault  Insertion  and  Instrumentation  System 

Fuzzy  Inference  Language 

Fault  Injection  Manager 

Flight-Plan  Interactive  Negotiation  and 

Decision-Aiding  System  for  Enroute  Rerouting 

Fault  Injection  Receptor 

FORTRAN  Library  for  EXpert  systems 

Frequency  Modulated 

Frequency  Modulation 

Flight  Management  Computer 

Failure  Mode  and  Effect  Analysis 

Failure  Modes  and  Effects  Criticality  Analysis 

Failure  Mode,  Effects,  and  Criticality  Analysis 

Flight  Management  System 

Field  of  View 

Function  Point 

Finite  State  Machine 

feet 

Fault  Tolerant 
Fault  Tree  Analysis 
Fault  Tree  Compiler 
Fault-Tolerant  Multiprocessor 
Fault  Tolerant  Processor 


G/E  (13) 
gl  (19) 
g2  (19) 
g3  (19) 
g4  (19) 

GA  (18) 

GaAs  (6,16,19,20) 
GaAsP  (19) 

GAMA  (6,18) 

GaP  (19) 

GCR  (6) 

GE  (5) 

GEMACS  (13) 

GEN  (5) 

GGLOSS  (5) 

GLOSS  (5) 

GNC  (16) 

GPC  (5) 

GPS  (11,12) 

GPWS  (11,12) 
Gr/Ep  (11,12) 


Graphite  Epoxy 
Grid  1 
Grid  2 
Grid  3 
Grid  4 

General  Aviation 
Gallium  Arsenide 
Gallium  Arsenide  Phosphide 

General  Aviation  Manufacturers  Association 
Gallium  Phosphide 
Group  Code  Recording 
General  Electric 

General  Electromagnetic  Model  for  the  Analysis 

of  Complex  Systems 

Generation 

Generalized  Gate— Level  Logic  System  Simulator 

Gate  Logic  Software  Simulator 

Guidance,  Navigation,  and  Control 

General  Purpose  Computer 

Global-Positioning-System 

Ground  Proximity  Warning  System 

Graphite/Epoxy 
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GS  (10) 
GUI  {20} 


Glideslope 

Graphical  User  Interface 


H-FIELD  {11,12} 

HI  {11,12} 

HA  {18} 

HARP  {5,18} 

HDBK  {5} 

HDD  {19} 

HDLC  {6,18} 

HERF  {5,14,16,18} 

HF  {11,12,13,14,19} 
Hg  {19} 

HIRF  {15,18,19} 

HLD  {19} 

HMD  {19} 

HMS  {19} 

HOL  {17,20} 

HSI  {3,19} 

HSRB  {6,18} 

HUD  {19} 

HVDC  {15} 

HW  {18} 

Hz  {3,15,18,19} 


Magnetic  Field 
Fan  Speed 
Hazard  Analysis 

Hybrid  Automated  Reliability  Predictor 
Handbook 

Head-Down  Display 
High-Level  Data  Link  Control 
High-Energy  Radio  Frequency 
High-Frequency 
Mercury 

High-Intensity  Radiated  Fields 

Head-Level  Display 

Helmet  Mounted  Displays 

Helmet  Mounted  Sight 

High  Order  Language 

Horizontal  Situation  Indicator 

High-Speed  Ring  Bus 

Head— Up  Display 

High  Voltage  dc 

Hardware 

Hertz 


I  {13} 
I  {17} 


I-dot  {13} 

I/O  {5,10,15,18,20} 
IAA  {3} 

IAAC  {11,12} 


I ACS  {18} 

IBM  {5} 

IC  {3,18,19,20} 

ICAO  {14} 

ICIS  {5} 

ICS  {5} 

ID  {5} 

ID  {18} 

IDG  {11,12} 

IEEE  {5,6,9,17,18,20} 

IF  {19} 

IETM  {20} 

IFC  {17} 

IFCS  {18} 

IFF  {14,19} 

IGGLOSS  {5} 


Current 

Intelligence  Content 

Derivative  of  the  current  with  respect  to  time 
Input/Output 

Integrated  Assurance  Assessment 
Integrated  Application  of  Active  Controls 
Technology  (to  an  Advanced  Subsonic  Transport 
Proj  ect) 

Integrated  Avionic  Computer  System 
International  Business  Machines 
Integrated  Circuit 

International  Civil  Aviation  Organization 

Intercomputer  Interface  Sequencer 

Intercomputer  Sequencer 

Identification 

Identifier 

Integrated  Drive  Generator 
Institute  of  Electrical  and  Electronics 
Engineers ,  Incorporated 
Forward  Current 

Interactive  Electronic  Technical  Manual 
Information  Flow  Complexity 
Information  Frame  Check  Sequence 
Identification  -  Friend  or  Foe 

Gate  Logic  Software  Simulator  (improved  version 
developed  at  NASA  Langley) 
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IJCNN  (20) 

International  Joint  Conference  on  Neural 
Networks 

ILS  {3,11,12,19} 

Instrument  Landing  System 

IMR  {18} 

Interrupt  Mask  Register 

INS  {6,11,12,19} 

Inertial  Navigation  System 

I OP A  {5} 

Input/Output  Processor  -  Channel  A 

IOS  {5} 

Input/Output  Subsystem 

IR  {19} 

Infrared 

IRS  {11,12,19} 

Inertial  Reference  System 

ISO  {17,18} 

International  Standards  Organization 

ITO  {19} 

Indium  Tin  Oxide 

ITS  {19} 

Intelligent  Tutoring  System 

ITT  {16} 

(Consultative  Committee  for)  International 
Telegraphy  and  Telephony 

IV&V  {9,20} 

Independent  Verification  and  Validation 

IVT  {18} 

Interrupt  Vector  Table 

JPL  {5} 

Jet  Propulsion  Laboratories 

k  {6,20} 

Thousand 

kA  {13,16} 

Kiloampere 

KBAP  {20} 

Knowledge— Based  AutoPilot 

kHz  {5,6,12,14,19} 

Kilohertz 

km  { 6 } 

kilometer 

L  {17} 

Estimated  Program  Level 

L  {17} 

Program  Level 

LAN  {5} 

Local  Area  Network 

LaRC  {5} 

Langley  Research  Center 

LC  {19} 

Liquid  Crystal 

LCC  {11,12} 

Life  Cycle  Cost 

LCD  {16} 

Liquid  Crystal  Display 

LCS  {19} 

Liquid  Crystal  Shutter 

LED  {6,19,20} 

Light  Emitting  Diode 

LF  {13} 

Low  Frequency 

LISP  {20} 

LISt  Processor 

LOC  {11,12} 

Localizer 

LOFT  {19} 

Line  Oriented  Flight  Training 

LPN  {13} 

Lumped  Parameter  Network 

LRC  {6} 

Longitudinal  Redundancy  Check 

LRRA  {11,12,19} 

Low  Range  Radio  Altimeter 

LRU  {5,6,11,12,13,18,19} 

Line  Replaceable  Unit 

LSB  {6,18} 

Least  Significant  Bit 

LSI  {5,18,19} 

Large  Scale  Integration 

LTPB  {6,18} 

Linear  Token  Passing  Bus 

LTRI  {13} 

Lightning  and  Transients  Research  Institute 

LVDT  {15} 

Linear  Variable  Differential  Transformers 

LVDT  {3} 

Linear  Voltage  Differential  Transducer 

m  {18} 

Original  Address  of  Last  Transmission 

m  { 6 } 

meter 

M  {6} 

Million 
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M  (5) 

Mutual  (when  used  with  RLC) 

mA  { 3 } 

Milliampere 

MAADS  {6} 

Multibus  Avionic  Architecture  Design  Study 

MAC  {4} 

Mean  Aerodynamic  Chord 

MAFT  {16} 

Multicomputer  Architecture  for  Fault  Tolerance 

Mbps  {6,16} 

Million  bytes  per  second 

MC  {18} 

Mode  Code 

MCDP  {11,12} 

Maintenance  Control  and  Display  Panel 

MCDU  {19} 

Multi-Purpose  Control  Display  Unit 

MCFCS  {18} 

Message  Control  Frame  Check  Sequence 

MCP  {11,12} 

Mode  Control  Panel 

MDICU  {4,5} 

Modular  Digital  Interface  Conversion  Unit 

MDICU  {3} 

Modular  Digital  Interface  Control  Unit 

MDT  {6} 

Mean  Down  Time 

MEP  {20} 

Mission  Equipment  Package 

MFCS  (18) 

Message  Frame  Check  Sequence 

Mflops  {16} 

Million  floating-point  operations  per  second 

MFM  {6} 

Modif ied-Frequency  Modulation 

MFR  {10} 

Mean  Failure  Rate 

MHz  {5,6,12,14,18,20} 

Megahertz 

mil  {11,12} 

One  thousandths  of  an  inch  (0.001) 

MIL  {5} 

Military 

MIL-HDBK  {18} 

Military  Handbook 

MIL-STD  {6,18} 

Military  Standard 

MKR  {19} 

Markers 

ML  {18} 

Message  Length 

MLE  {8} 

Maximum  Likelihood  Estimates 

MLS  {11,12,19} 

Microwave  Landing  System 

mm  {19,20} 

Millimeter 

Mn  {19} 

Manganese 

MOS  {5} 

Metal-Oxide  Semiconductor 

MPP  {16} 

Massively  Parallel  Processor 

MPSC  {18} 

Multi-Protocol  Serial  Controller 

MPX  {5} 

Multiplex 

ms  {6,10,18} 

Millisecond 

MSB  {6,18} 

Most  Significant  Bit 

MSE  {11,12} 

Magnetic  (Field)  Shielding  Effectiveness 

MSI  {5} 

Medium  Scale  Integration 

MT  {18} 

Message  Time 

MTBCF  {6} 

Mean  Time  Between  Critical  Failures 

MTBF  {9,18} 

Mean  Time  Between  Failures 

MTTF  {8,10} 

Mean  Time  to  Failure 

MTTR  {6,18} 

Mean  Time  To  Repair 

Mux  { 5 } 

Multiplexed 

MUX  {4,18} 

Multiplexer 

N  {17} 

Estimated  Length 

n  {18} 

Address  of  User  Performing  Computation 

N  {18} 

Maximum  Number  of  Users 

N  {17} 

Implementation  Length  of  a  Program 

Nj.  {15} 

Low  Rotor  Speed 

Nx  {17} 

Total  Number  of  Operator  Occurrences 
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Nx*  {17} 

N2  (15) 

N2  {11,12} 

Nz  {17} 

N2*  {17} 

NA  {6} 

NA  {3} 

NADC  {6,7} 

Naecon  { 5 } 

NAECON  {6} 

NAND  {5} 

NAS  {19} 

NASA  {2,3,5,7,13,15,18,19,20} 
NASC  {13} 

NATO  {14} 

NB  {11,12} 

NCTS  {18} 

ND  {19} 

NEC  {13} 

NEMP  {5,12} 

NHPP  {8} 
nmi  { 14} 

NN  {20} 

NPRM  {14} 

NRZ  {6} 

NRZ-I  {6} 

NRZ-L  {6} 
nsec  {6} 

NSWC  {13} 

NTSB  {19} 

NVG  {19} 

NVS  {8} 


Minimum  Number  of  Operators 
High  Rotor  Speed 
Core  Engine  Speed 

Total  Number  of  Operand  Occurrences 
Minimum  Number  of  Operands 
Numerical  Acceptance 
Normal  Accelerometers 
Naval  Air  Development  Center 

National  Avionics  and  Electronics  Conference 
National  Aerospace  and  Electronics  Conference 
Not  AND 

National  Airspace  System 

National  Aeronautics  and  Space  Administration 

Naval  Air  Systems  Command 

North  Atlantic  Treaty  Organization 

Narrow  Band  Signal 

Not  Clear  To  Send 

Navigation  Display 

Numerical  Electromagnetics  Code 

Nuclear  Electromagnetic  Pulse 

Non— Homogeneous  Poisson  Process 

nautical  mile 

Neural  Network 

Notice  of  Proposed  Rulemaking 
Non-return  to  Zero 
Non— return  to  Zero  Inverted 
Non— return  to  Zero  Dual  Level 
Nanosecond 

Naval  Surface  Weapons  Center 
National  Transportation  Safety  Board 
Night  Vision  Goggles 
N— version  Software 


OMEGA  {11,12} 
OMV  {16} 

ONR  {20} 

OS  {5} 

OSI  {18} 

OTV  {16} 


Very  Low  Frequency  Navigation 
Orbital  Maneuvering  Vehicle 
Office  of  Naval  Research 
Operating  System 
Open  Systems  Interconnection 
Orbital  Transfer  Vehicle 


P-Static  {11,12} 
P  {10} 

PA  {19} 

PA  {20} 

PAI  { 19 } 

PAL  {5} 

PAS  {6} 

PAWS  {5} 

PBW  {15} 

PC  {17} 

PC  {5,20} 

PCA  {17} 


Precipitation  Static 

Processor 

Public  Address 

Pilot's  Associate 

Primary  Attitude  Instrument 

Programmable  Array  Logic 

Pilot  Assist  System 

Pade  Approximation  With  Scaling 

P  o we  r — By— W ire 

Processing  Complexity 

Personal  Computer 

Processing  Complexity  Adjustment 
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PCS  {16} 

Primary  Control  System 

PCU  {11,12} 

Power  Control  Unit 

pdf  {8} 

Probability  Density  Function 

PE  {6} 

Phase  Encoding 

PE  {20} 

Processing  Element 

pf  (12) 

picofarad 

PFD  {19} 

Primary  Flight  Display 

PGA  {20} 

pin  grid  array 

PLA  {15} 

Power  Level  Actuator 

PLA  {16} 

Power  Level  Angle 

PMA  {18} 

Parts  Manufacturer  Approval 

PMA  {20} 

Portable  Maintenance  Aid 

PMS  {5} 

Physical  Message  Switch 

PNF  {19} 

Pilot  Not  Flying 

PNI  {19} 

Primary  Navigation  Instrument 

PRF  {11,12} 

Pulse  Repetition  Frequency 

PROC  {5} 

Processor 

PROLOG  (20) 

PROgramming  in  LOGic 

PROM  {3,10,17,18} 

Programmable  Read-Only  Memory 

psi  {15} 

pounds  per  square  inch 

PVI  {16,19} 

Pilot-Vehicle  Interface 

PWM  {11,12} 

Pulse  Width  Modulation 

PZ  {15} 

Piezoelectric 

QUAD  {5} 

Quadruple 

R  {13} 

Resistance 

R-C  {12} 

Resistor-Capacitor 

RADC  {8,17} 

Rome  Air  Development  Center 

RAE  {13} 

Royal  Aircraft  Establishment 

RAE  {20} 

Royal  Aerospace  Establishment 

RAM  (3,5,10,16,17,18) 

Random  Access  Memory 

RAT  {6,18} 

Ring  Admittance  Timer 

RB  {8} 

Recovery  Block 

RBDCP  (3) 

Reliability  Block  Diagram  Computer  Program 

RCA  (16) 

Radio  Corporation  of  America 

RCP  {19} 

Reconf igurable  Cockpit 

RCVR  {5} 

Receiver 

RDFCS  {3} 

Redundant  Digital  Flight  Control  System 

RDFCS  {4} 

Reconf igurable  Digital  Flight  Control  System 
(facility) 

RDFCS  { 5 } 

Reconf igurable  Digital  Flight  Control  System 

RDMI  (11,12) 

Radio  Distance  Magnetic  Indicator 

RE  {11,12} 

Radiated  Emission 

REG  {5} 

Register 

REL  {3} 

Reliability 

REL  COMP  {3} 

Reliability  Computers 

RF  {5,11,12,13,14,16,18} 

Radio  Frequency 

RFI  {11,12} 

Radio  Frequency  Interference 

RIM  {18} 

Ring  Interface  Module 

RISC  {20} 

Reduced  Instruction  Set  Computer 

RIU  {18} 

Ring  Interface  Unit 
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RL  {13,15} 

Rl  (19) 

RLC  {5,13} 

RLCM  {13} 

RM  {7} 

RNRZ  {6} 

ROM  {5,10,19} 

RPA  {20} 

RPV  {16} 

RR  {18} 

RRT  {18} 

RS  {18} 

RS  {11,12} 

RSS  {4,7} 

RT  {5,18} 

RTCA  {2,3,11,12,14, 
16,17,18,20} 


RTE  {18} 
RTI  {5} 
RTS  {18} 
RZ  {6} 


Resistance/Inductance  (Out  of  order  in  c.15) 

Load  Resistor 

Resistance/Inductance/Capacitance 

Resistance/Inductance/Capacitance/Mutual 

Redundancy  Management 

Randomized  Non-return  to  Zero 

Read  Only  Memory 

Rotorcraft  Pilot's  Associate 

Remotely  Piloted  Vehicle 

Read  Register 

Ring  Rotation  Time 

Recommended  Standard 

Radiated  Susceptibility 

Relaxed  Static  Stability 

Remote  Terminal 

Radio  Technical  Commission  for  Aeronautics  (now 
known  as  Requirements  and  Technical  Concepts  for 
Aviation) 

Real-Time  Executive 
Remote  Terminal  Interface 
Request  To  Send 
Return  to  Zero 


S  (17) 

S/A  {11,12} 

S-a-0  {5,10} 

S-a-1  {5,10} 

S-GLOSS  {5} 

SAE  {2,5,6,13,14,16, 
17,18,19,20} 


SAI  {18} 

SAS  {4,7} 
SATCOM  {19} 
SATNAV  {19} 
SC  {18} 

SC  {20} 

SCC  {18} 

SCM  {18} 

SCP  {18} 

SD  {19} 

SDF  {7} 

SE  {11,12} 
SELCAL  (19} 
SEU  (5) 

SG  {18} 

SHF  {11,12} 
SHRD  {5} 
SIAM  {15} 


Stroud  Number 
Spectrum  Analyzer 
Stuck  at  Zero 
Stuck  at  One 

Gate  Logic  Software  Simulator  developed  by 
Stevens 

Society  of  Automotive  Engineers  (now  known  as 
Engineering  Society  for  Advanced  Mobility  Land 
Sea  Air  and  Space) 

Systems  Architecture  and  Interfaces 

Stability  Augmentation  System 

Satellite  Communications 

Satellite  Navigation 

Special  Condition 

Special  Committee 

System  Configuration  Controller 

Software  Configuration  Management 

Self-Checking  Pair 

System  Display 

Super-Diagnostic  Filter 

Shielding  Effectiveness 

Select  Call 

Single  Event  Upset 

Synchronization  Gap 

Super  High-Frequency 

Shared 

Society  for  Industrial  and  Applied  Mathematics 
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SIF  {14} 

SIM  {18} 

SIR  {18} 
SLRT  {7} 

SMF  {18} 
SMOTEC  {14} 

SO  {17} 

SOP  {19} 
SPRT  {7} 

SQA  {18} 

SQF  {17} 

SQL  {5} 

SQM  {17} 
SQPP  {17} 
SRS  {17} 

SSA  {18} 

SSI  {5} 

SSP  {3} 

SSPC  {15} 
SSS  {17} 
STANAG  {14} 
STC  {2} 

STC  {18,20} 
STEM  { 5 } 

STN  {19} 
STOL  {16} 
str  {6} 

SURE  {5} 

SW  {18} 

SYN  {5} 


Selective  Identification  Facility 
Serial  Interface  Module 
Shared  Interface  RAM 
Sequential  Likelihood  Ratio  Test 
Self  Monitor  Function 

Special  Missions  Operation  Test  and  Evaluation 
Center 

Second  Order  (Average) 

Standard  Operating  Procedure 
Sequential  Probability  Ratio  Test 
Software  Quality  Assurance 
Software  Quality  Factor 
Software  Query  Language 
Software  Quality  Metrics 
Software  Quality  Program  Plan 
Software  Requirement  Specification 
System  Safety  Assessment 
Small  Scale  Integration 
Servo  Simulation  Panel 
Solid-State  Power  Controller 
System/Segment  Specification 
Standardization  Agreement  (NATO) 

Supplemental  Type  Certification 
Supplemental  Type  Certificate 
Scaled  Taylor  Expansion  Matrix 
Supertwisted  Nematic 
Short  Takeoff  and  Landing 
string 

Semi— Markov  Unreliability  Range  Evaluator 

Software 

Synch 


T  {17} 

T/R  {6} 

TACAN  {14,19} 

TASRA  {3} 

Tc  {18} 

TC  {2} 

TC  {18,20} 

TCAP  {13} 

TCAS  {11,12,16,18} 
TCL  {13} 

TDM  {6} 

TDMA  {18} 

Tf  {18} 

TEAMS  {20} 

TFCS  {18} 

TFEDF  {18} 

TFEL  {19} 

TFT  {19} 

TG  {18} 

THT  {6,18} 


Estimated  Programming  Time 

Transmitter/Receiver 

Tactical  Air  Navigation 

Tree  Aided  System  Reliability  Analysis 

Count  Duration 

Type  Certification 

Type  Certificate 

Threshold  Circuit  Analysis  Program 

Traffic  Alert  and  Collision  Avoidance  System 

Transient  Control  Level 

Time  Division  Multiplex 

Time  Division  Multiple  Access 

Frame  Time 

Technical  Expert  Aircraft  Maintenance  System 

Token  Frame  Check  Sequence 

Token  Frame  Ending  Delimiter  Field 

Thin-Film  Electroluminescence 

Thin-Film  Transistor 

Terminal  Gap 

Token-Holding  Timer 
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TI  {18} 

TLA  {11,12} 

Tm  {18} 

TMC  {11,12} 

TMR  {10} 

TN  {19} 

TRT  {18} 

TRU  {15} 

TSDF  {18} 

TSO  {18,19,20} 

TTL  {5,11,12,13,16,19,20} 
TV  {14} 

TWTD  {13} 

TX  {5} 


Transmit  Interval 
Thrust  Lever  Angle 
Wait  Time  for  User 
Thrust  Management  Computer 
Triple  Modular  Redundant 
Twisted  Nematic 
Token  Rotation  Timer 
Transformer  Rectifier  Unit 
Token  Starting  Delimiter  Field 
Technical  Standard  Order 
Transistor-Transistor  Logic 
Television 

Thin  Wire  Time  Domain 
Transmit 


U.K.  {13,14} 

U.S.  {14} 

UAC  {18} 

UART  {15} 

UHF  {11,12,13,14,19} 
UNC  {18} 

UNIBUS  {5} 

UPS  {15} 

USAF  {16,20} 

USB  {16} 

USEG  {5} 

UUT  {20} 

UV  (19) 


United  Kingdom 
United  States 

Unbalanced  Asynchronous  Configuration 
Universal  Asynchronous  Receiver  Transmitter 
Ultra  High-Frequency 
Unbalanced  Normal  Configuration 
Universal  Bus 

Uninterruptible  Power  Supplies 
United  States  Air  Force 
Upper  Surface  Blowing 
Unsegmented 
Unit  Under  Test 
Ultra-Violet 


V  {17} 

V  {19} 

V/m  {14} 

V*  {17} 

V&V  {18,20} 

VB  119) 

Vcc  U9) 

VF  {19} 

VFD  {19} 

VHF  {11,12,13,14,19} 
VHSIC  {6,16} 

VLF  {11,12,19} 

VLSI  {5,6,14,18,20} 
VLSIC  {6,16} 

VOR  {11,12,14,18,19} 
VORTA/VHF  {11,12} 

VRC  {6} 

Vs  {19} 

VSI  {11,12} 

VSV  {15} 

VT  {18} 

VTOL  {16} 


Volume 

Volt 

Volt/meter 
Potential  Volume 
Verification  and  Validation 
Breakdown  voltage 
Collector  Circuit  Voltage 
Forward  Voltage 
Vacuum  Florescent  Display 
Very  High-Frequency 

Very-High-Speed  Integrated  Circuits 

Very  Low-Frequency 

Very  Large  Scale  Integration 

Very  Large  Scale  Integrated  Circuits 

VHF  Omnidirectional  Range 

Omnirange/Tactical  Air  Navigation 

Vertical  Redundancy  Check 

Sustain-Voltage 

Vertical  Speed  Indicator 

Variable  Stator  Vane 

Validation  Testing 

Vertical  Takeoff  and  Landing 
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W/P  {15} 

Fuel  Flow  to  Burner  Pressure 

WAI  (3) 

Warning  Annunciation  Indicator 

WFM  {15} 

Main  fuel  metering  valve  actuator  sensor 

WR  {18} 

Write  Register 

WRU  {11,12} 

Weapons  Replaceable  Unit 

WSO  {17} 

Weighted  Second  Order  (Average) 

XAB  {5} 

Transmit  Compare  A  B 

XMT  {5} 

Transmit 

XMTR  {3} 

Transmitter 

XOR  {5} 

Exclusive  OR 

ZM  {6} 

Zero  Modulation 

ZnS  {19} 

Zinc  Sulfide 

ZnSe  {19} 

Zinc  Selenide 
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